Zusammenfassung

  • Ein übermittelter Dateiname bezeichnet keine Befugnis, einen lokalen Speicherpfad festzulegen. Auch ein korrekt aufgebauter Multipart-Body bestätigt weder Vertraulichkeit noch die Erlaubnis zur Verarbeitung.
  • Die Spezifikation von 2015 verbietet das Zusammenführen gleichnamiger Teile und das Umordnen durch Vermittler. Eine frühzeitige Reduktion auf Einzelwerte kann deshalb erhaltene Informationen wieder beseitigen.

Ein Dateiname ist zunächst eine Mitteilung des Absenders. Er ist kein Auftrag an den Empfänger, genau dort eine Datei anzulegen. Diese nüchterne Grenze gehört zu den aussagekräftigsten Stellen in Larry Masinters Multipart-Arbeit. Wer nur an den Upload-Knopf im Browser denkt, übersieht, wie viele Entscheidungen zwischen einem angekommenen Body und einem verlässlichen Vorgang liegen.

Was ein Name tatsächlich bezeichnet

RFC 7578, veröffentlicht im Juli 2015, beschreibt einen Body als Folge von Teilen, die durch eine Begrenzung getrennt sind. Jeder Teil führt eine Content-Disposition-Kopfzeile vom Typ form-data und einen name-Parameter für das ursprüngliche Feld. So lassen sich Text und Dateiinhalte gemeinsam transportieren, ohne ihre Grenzen aufzugeben. Die Definition reicht ausdrücklich über HTML und HTTP hinaus, bis zu Anwendungen ohne einen Menschen, der ein sichtbares Formular ausfüllt.

Der Feldname und filename erfüllen unterschiedliche Aufgaben. Für Dateiinhalte empfiehlt die Spezifikation einen Dateinamen, lässt ihn aber entfallen, wenn er nicht verfügbar, bedeutungslos oder privat ist. Ein Gerätestrom benötigt keinen erfundenen Desktop-Dateinamen. Der Empfänger darf einen gelieferten Namen nicht blind übernehmen und enthaltene Verzeichnispfade nicht als lokale Speicheranweisung behandeln. Die Hoheit über den eigenen Dateiraum bleibt bei der empfangenden Anwendung.

Auch die Zuordnung zum ursprünglichen Formular erledigt das Format nicht selbst. Die Anwendung kann Kontext etwa über ihr Verarbeitungsziel oder mitgegebene Daten bestimmen. Der Body besitzt jedoch keinen eingebauten Mechanismus, der diesen Ursprung bestätigt. Multipart gewährleistet ebenso wenig Vertraulichkeit oder Integrität. Das ist kein hier getesteter Sicherheitsfehler, sondern eine ausdrücklich begrenzte Zuständigkeit des Formats.

Der zweite Teil darf nicht verschwinden

Eine andere Grenze wird sichtbar, wenn zwei Belege zu einem Upload-Feld gehören. Sie treffen als getrennte Teile mit demselben Feldnamen ein. Eine Hilfsfunktion macht daraus ein Wörterbuch mit nur einem Wert je Name und behält den letzten Beleg. Die Übertragung muss dafür nicht beschädigt sein: Der Verlust entsteht erst bei der Darstellung für die Anwendung. Dieses Beispiel erläutert einen möglichen Mechanismus und berichtet keinen Vorfall in einer bestimmten Bibliothek.

Die Regel in Abschnitt 5.2 der Fassung von 2015 schützt solche Unterschiede. Verarbeiter von Formularen mit wohldefinierter Reihenfolge sollten die Ergebnisse in dieser Reihenfolge zurückgeben. Vermittler dürfen sie nicht umordnen; Teile mit identischen Feldnamen dürfen nicht zusammengeführt werden. Die erste Vorgabe ist ein SHOULD und verlangt nicht, jeder denkbaren Form eine natürliche Reihenfolge zu erfinden. Die beiden Verbote sichern bereits vorhandene Merkmale der Eingabe.

Mehrere gleichnamige Teile können sogar zwingend zur richtigen Darstellung gehören. Abschnitt 4.3 verlangt für mehrere Dateien eines Feldes getrennte Teile mit demselben name. Die ältere Verschachtelung als multipart/mixed wird zugunsten der verbreiteten Praxis aufgegeben. Für breit einsetzbare Empfänger empfiehlt der Haupttext zugleich, auch die alte Methode zu unterstützen. Damit wird eine Migration beschrieben, keine bedingungslose Pflicht jeder Anwendung, sämtliche historischen Eingaben anzunehmen.

Ein Einzelwert kann nach einer bewusst geprüften Anzahl und einer ausdrücklich gewählten Fachregel sinnvoll sein. Vor dieser Prüfung beseitigt er womöglich den Beleg, dass zwei Werte eingingen. Eine Folge oder Mehrwertdarstellung erhält die Möglichkeit, den Eingang zu untersuchen. Sie erteilt aber keine Erlaubnis, jeden Teil als zulässige Geschäftsaktion zu behandeln. Wiedergabetreue und Autorisierung sind nicht dasselbe.

Eine Spezifikation muss mit ihrem Erbe leben

Die Vorgeschichte beginnt hier mit RFC 1867 von E. Nebel und L. Masinter, November 1995. Gewöhnliche HTML-Formulare konnten lokale Dateien nicht einheitlich anfordern. Der Vorschlag verband Dateiauswahl, eine MIME-kompatible Übermittlung und einen Übergang für ältere Browser. Er war Experimental und ausdrücklich kein Internetstandard. Aus der Veröffentlichung allein lässt sich keine damalige flächendeckende Umsetzung ableiten.

RFC 2388, unter L. Masinters Namen im August 1998, gehörte zum Standards Track. Sein Abschnitt 5.5 ließ die Beziehung zwischen Feld- und Ergebnisreihenfolge sowie die Behandlung gleicher Feldnamen undefiniert. RFC 7578 löste ihn 2015 ab und präzisierte gerade diese Punkte. Auch dieser Text nennt Masinter als Autor, dokumentiert aber öffentliche Prüfung und den Konsens der IETF-Gemeinschaft. Die persönliche Leistung liegt in einer fortgesetzten Arbeit an der Spezifikation, nicht in einer Alleinerfindung von MIME oder sämtlichem Browserverhalten.

Das Erbe zeigt sich ebenfalls bei Zeichenkodierungen. Die neuere Fassung rät für breite Interoperabilität zu ASCII-Feldnamen oder zu einheitlichem UTF-8, wenn andere Zeichen unvermeidbar sind. Sie beschreibt Konventionen für einen Standardzeichensatz und verschiedene ältere Verfahren. filename* ist in diesem Format verboten; eine Regel aus einem anderen Kopfzeilenkontext lässt sich nicht ungeprüft übertragen. Ein gewachsener Standard muss vorhandene Praktiken ordnen, statt eine einzige Dekodierungsannahme als zeitlose Wahrheit auszugeben.

Quellen und Aussagegrenzen

Die drei verlinkten RFCs tragen diese historische Analyse. Der Text von 1995 warnt bereits vor dem Senden lokaler Dateien ohne ausdrücklichen Wunsch des Nutzers; die Fassung von 2015 behandelt unbeabsichtigte Offenlegung, Überschreiben und ausführbare Inhalte. Masinters alte persönliche Seite ist zeitlich auf 2014 bezogen und belegt keinen heutigen Arbeitgeber. Es gibt hier keine aktuelle Bibliotheksprüfung, Verlustquote oder Angriffsmessung. Die öffentliche Referenzaufnahme verankert die Identität des KI-generierten redaktionellen Porträts; die Arbeitsumgebung dahinter ist erfunden.