Zusammenfassung

  • RFC 1867 und RFC 2388 beschrieben mehrere Dateien aus einem Formularfeld als inneren multipart/mixed-Teil in multipart/form-data.
  • RFC 7578 vermerkte, dass keine Sender-Implementierungen dieser Form bekannt waren. Es machte jede Datei zu einem äußeren Teil mit demselben Feldnamen und ließ die Empfangskompatibilität mit der alten Verschachtelung bestehen.

Vom Dateiauswahlfeld zum Übertragungsformat

Bevor Browser Dateien über einen gemeinsamen Formularweg senden konnten, brauchten Dienste oft eigens gebaute Clientsoftware. RFC 1867 schlug 1995 ein HTML-Steuerelement INPUT TYPE=FILE und eine MIME-Darstellung vor, die gewöhnliche Formularwerte zusammen mit Dateiinhalt übertragen konnte. Der Text hatte den Status Experimental, war also noch kein fertiger Internetstandard. Auch eine Übergangslösung für Benutzerprogramme ohne Upload-Funktion war Teil des Vorschlags.

Die Darstellung bestand aus zwei Ebenen. Der äußere multipart/form-data-Teil nannte das Formularfeld. Wählte jemand in diesem Feld mehrere Dateien aus, sammelte ein innerer multipart/mixed-Teil diese Dateien. Auf dem Papier hatte jede Verpackung eine klare Aufgabe: außen die Zuordnung zum Feld, innen die Dateimenge.

RFC 2388 erhielt 1998 den Status Standards Track und definierte multipart/form-data unabhängig von HTML und HTTP; auch andere Anwendungen konnten es für zurückgegebene Formularwerte verwenden. Doch für mehrere Dateien in einem Feld blieb der innere multipart/mixed-Teil erhalten. Was im experimentellen Vorschlag als Beispiel stand, wurde Teil einer wiederverwendbaren Spezifikation.

Die Überarbeitung kannte keine Sender dieser Form

RFC 7578 löste RFC 2388 im Jahr 2015 ab und beschrieb die Lücke zwischen Vorgabe und bekannten Absendern ungewöhnlich deutlich. Die verschachtelte Form wurde für Erzeuger nicht mehr empfohlen und von Empfängern nicht mehr zwingend verlangt, weil keine Sender bekannt waren, die sie implementierten. Um zu den ermittelten Implementierungen zu passen, sollte jede Datei einen eigenen äußeren Formulardatenteil erhalten. Teile desselben Steuerelements wiederholen dabei denselben name-Parameter.

Die Gruppierung wanderte also. Früher enthielt ein benannter Teil eine innere Dateiliste. Danach standen mehrere gleichrangige Teile im äußeren Strom; ihr gemeinsamer Feldname ordnete sie dem gleichen Steuerelement zu. RFC 7578 erklärte die alte Form nicht für ungültig. Empfänger für einen breiten Einsatz sollten sie weiterhin verstehen können. Die Senderregel änderte sich, während die Rückwärtskompatibilität beim Lesen wichtig blieb.

„Keine bekannten Sender-Implementierungen“ beschreibt den Wissensstand der Autoren von RFC 7578. Es beweist nicht, dass jemals kein Programm die Verschachtelung gesendet hat, und nennt weder Produkt noch Marktanteil, Umstellungszeitpunkt oder Fehlerrate. Belegt ist eine engere Aussage: Die Nachfolgespezifikation änderte die beschriebene Drahtform, weil ihre Autoren keine Sender für die ältere Struktur benennen konnten.

Wiederholte Namen sollten Werte nicht verschlucken

RFC 2388 hatte außerdem offengelassen, ob die Reihenfolge der Formularfelder in den zurückgegebenen Teilen erhalten bleiben sollte und was doppelte Feldnamen bedeuten. RFC 7578 verlangt, eine vom Formular festgelegte Reihenfolge zu bewahren, untersagt Vermittlern eine Umordnung der Ergebnisse und verbietet, Teile mit identischem Namen zusammenzufassen. Ein wiederholter Name kann damit mehrere Werte desselben Feldes markieren, statt als Schlüsselkonflikt zu verschwinden.

Das war keine Ablösung der MIME-Struktur. Die Grenzen zwischen den Teilen blieben erhalten, und nicht jedes Formular besitzt eine natürliche Reihenfolge. Die Änderung betraf den konkreten Mehrfachdatei-Fall: mehrere Geschwisterteile tragen denselben Feldnamen. Gesamtanfrage, beabsichtigte Reihenfolge, Teilinhalt und Interpretation der empfangenden Anwendung bleiben dennoch getrennte Vorgänge.

Laufender Code als Beleg

Heng Lu betont in seinem Text über Running-Code-Primacy den Unterschied zwischen einer Protokollbeschreibung und ausgeführtem Verhalten. RFC 2388 zeigt das im kleinen, nachvollziehbaren Maßstab: RFC 7578 konservierte eine frühere Empfehlung nicht allein wegen ihres Alters. Die Autoren richteten die Mehrfachdateiform an den Sendern aus, die sie belegen konnten, und ließen zugleich einen Kompatibilitätspfad für Empfänger der alten Form offen.

Die Akte sagt nicht, wer die Änderung anstieß, wie viele Systeme beteiligt waren oder welche Betriebskosten ausschlaggebend waren. Sie zeigt weder, dass Implementierer stets recht haben, noch dass Standards jede Softwaregewohnheit übernehmen sollten. Die begrenzte Lehre lautet: eine Drahtform beschreiben, Systeme suchen, die sie tatsächlich senden, und beim Ändern der Regel das Lesen älterer Daten mitdenken.

Quellen