Zusammenfassung

  • RFC 1806 führte inline, attachment und einen optionalen Dateinamen als gewünschte Darstellung ein; das Feld bescheinigte weder Anzeige noch Speicherung.
  • Die Empfängerseite musste Pfadbestandteile entfernen, Kollisionen verhindern und Namen abwehren, die Startdateien, Systemdateien, Befehle oder Pipes beeinflussen konnten.
  • Spätere Standards überführten den Mechanismus von einem MIME-Experiment in E-Mail-, HTTP- und Formularkontexte, ohne aus dem Namensvorschlag eine lokale Berechtigung zu machen.

MIME transportierte Inhalte, aber keine einheitliche Oberfläche

RFC 1521 machte Internet-Mail zu einem Behälter für Text, Bilder, Anwendungsdaten und verschachtelte Multipart-Strukturen. RFC 2045 und RFC 2046 ordneten die Syntax später neu. Ein Empfänger konnte Teile abgrenzen, Transferkodierungen auflösen und den behaupteten Medientyp bestimmen.

Damit war noch keine Oberfläche festgelegt. Eine grafische Mailanwendung konnte ein Bild im Lesefluss zeigen; ein Textterminal konnte nur einen auswählbaren Eintrag anbieten. Ein deklarierter Typ sagte nicht, ob ein Decoder vorhanden oder eine automatische Darstellung vertretbar war.

Die im Juni 1995 experimentell veröffentlichte RFC 1806 schlug deshalb ein optionales Content-Disposition-Feld für jede MIME-Entität vor. Fehlte es, durfte der Mail User Agent selbst eine geeignete Darstellung wählen. Das Feld lieferte somit zusätzliche Absicht, entzog dem Empfänger aber keine Entscheidung.

Zwei Werte begrenzten den nächsten Schritt

inline bezeichnete eine gewünschte automatische Darstellung im gewöhnlichen Fluss, vorbehaltlich der Regeln des umgebenden Multipart-Elements. attachment verlangte vor der Darstellung eine weitere Benutzerhandlung. Wie diese Wahl sichtbar wurde, blieb dem lokalen Programm überlassen.

Die Begriffe berichteten keinen Vollzug. inline bewies weder Unterstützung des Formats noch bestandene Sicherheitsprüfung oder tatsächliche Wahrnehmung. attachment bewies keinen Klick und keine Datei. Ein Header konnte die beabsichtigte nächste Handlung dokumentieren; für ihr Ergebnis war ein späterer Beleg nötig.

Bei verschachtelten Entitäten gab es mehrere Schwellen. Eine Disposition am Multipart-Behälter galt dem Behälter als Ganzem. War er ein Anhang, wurden die Dispositionen seiner inneren Teile erst nach dem Öffnen relevant. Die äußere Kennzeichnung konnte daher den Zugriff auf den innersten Teil nicht bescheinigen.

Unbekannte Dispositionen sollten wie attachment behandelt werden, unbekannte Parameter durften ignoriert werden. Eine künftige Erweiterung erhielt nicht allein durch Neuheit das Recht auf automatische Exposition. Kompatibilität bedeutete hier, die Wirkung zu begrenzen statt unbekannte Semantik zu erfinden.

Der vorgeschlagene Name endete vor dem lokalen Pfad

Der optionale Parameter filename bot einen Standardnamen an, falls der Empfänger einen Teil abtrennen und archivieren wollte. Er durfte auch an einem Inline-Teil stehen, ohne je eine Datei zu erzeugen. Name im Protokoll und Name auf dem Datenträger waren verschiedene Tatsachen.

RFC 1806 verlangte, Verzeichnisangaben nicht zu beachten, den letzten brauchbaren Bestandteil an lokale Konventionen anzupassen und vorhandene Dateien nicht zu überschreiben. Der Absender kennt weder lokale Separatoren und reservierte Namen noch Schreibrechte, belegte Namen oder die Programme, die an Erweiterungen gebunden sind.

Der Sicherheitsteil nannte die Folgen: eine Startdatei anlegen, eine System- oder bestehende Datei ersetzen, ausführbaren Inhalt in einen Befehlssuchpfad stellen oder Daten an eine Pipe leiten. Benennung und Ablage durften keine Interpretation oder Ausführung ohne ausdrückliche Benutzerinitiative auslösen.

Zwischen Feld und Wirkung liegen daher mehrere Belege: rohe Zeichenfolge, Parsergebnis, Entfernung von Pfadbedeutung, Kollisionsentscheidung, tatsächlich gewählter lokaler Name und spätere Programmaktion. Wer nur den Header besitzt, kann die ersten Schritte untersuchen, aber keine fertige Speicherung behaupten.

Aus dem Experiment wurde ein Standard mit mehr Metadaten

Der Informationsdatensatz zu RFC 1806 verweist auf RFC 2183, die sie im August 1997 als Proposed Standard ersetzte. Sie behielt inline, attachment und die Verantwortung des Empfängers für Dateinamen bei. Hinzu kamen Erstellungs-, Änderungs- und Lesedatum sowie eine ungefähre Größe.

Das sah mehr nach einer Dateiakte aus, blieb aber übertragene Behauptung. RFC 2183 warnte Unix- und POSIX-Implementierer ausdrücklich: st_ctime ist keine Erstellungszeit. Der Empfänger konnte eine Datumsangabe übernehmen, nicht aus ihr eine authentische Herkunft ableiten. Die Größe half bei der Platzplanung, garantierte aber weder Zuweisung noch Integrität oder abgeschlossenen Schreibvorgang.

Die Revision regelte auch die Registrierung von Erweiterungen. Das heutige IANA-Register für Content Disposition enthält ursprüngliche und spätere protokollspezifische Werte. Ein registrierter Begriff hat eine öffentliche Definition; das beweist weder Implementierung in einem konkreten Client noch Austauschbarkeit zwischen Protokollpositionen.

Internationale Namen erweiterten die Darstellung, nicht die Rechte

RFC 1806 wies selbst auf die US-ASCII-Grenze ihrer Paramatersyntax hin. RFC 2231 führte nummerierte Fortsetzungen für lange Werte sowie eine erweiterte Form mit Zeichensatz, optionaler Sprache und prozentkodierten Oktetten ein.

Damit kamen neue Zustände hinzu: fehlende oder vertauschte Segmente, gemischte kodierte und unkodierte Abschnitte, unbekannte Zeichensätze und ungültige Bytes. Der fertige Unicode-Name ist ein Dekodierergebnis. Für Nachvollziehbarkeit müssen die rohen Abschnitte und die Auswahl erhalten bleiben.

Eine korrekte Dekodierung macht keinen sicheren Namen. Ein sauber rekonstruiertes Traversal bleibt ein Traversal, ein lesbarer reservierter Gerätename bleibt reserviert. Kodierung löst Repräsentation; Berechtigung bleibt lokale Politik.

Im Web ging Praxis der Norm voraus

Schon RFC 2616 hielt 1999 fest, dass Content-Disposition in HTTP häufig implementiert wurde, obwohl es kein Bestandteil des HTTP-Standards war. Server nutzten das aus Mail bekannte Muster, um getrennte Speicherung anzuregen und einen nützlichen Namen anzubieten.

Erst RFC 6266 standardisierte 2011 das HTTP-Antwortfeld. Dateinamen sind dort ausdrücklich nur Hinweise. Der User Agent muss unerlaubte Speicherorte verhindern, bis auf den letzten alle Pfadbestandteile verwerfen, gefährliche Erweiterungen prüfen, Steuerzeichen entfernen und Namen mit besonderer Datei- oder Shell-Bedeutung entschärfen.

Eine Antwort kann einen kompatiblen filename und einen erweiterten filename* enthalten; ein Empfänger, der beide versteht, soll den zweiten bevorzugen. RFC 8187 verfeinerte die HTTP-Parameterkodierung und verlangte UTF-8-Unterstützung. Welche Form gewann und wie sie dekodiert wurde, gehört zum Beleg, besonders wenn beide Werte voneinander abweichen.

Beim Upload wechselte die Empfangsseite

Content-Disposition steht auch in Multipart-Formulardaten, doch RFC 6266 schließt solche Body-Part-Felder aus ihrem Antwortprofil aus. RFC 7578 verlangt für jeden Teil form-data und einen name-Parameter; bei einem Dateiteil soll ein sinnvoller filename hinzukommen.

Nun sendet der Browser, während die Webanwendung ihr Dateisystem schützen muss. Sie soll das gelieferte Verzeichnis verwerfen, lokale Konventionen anwenden und den Speicherort selbst bestimmen. RFC 7578 untersagt in diesem Kontext sogar filename*, obwohl es in HTTP-Antworten vorgesehen ist. Gleicher Feldname bedeutet nicht gleiche Grammatik.

So entstand aus dem experimentellen MIME-Feld eine protokollübergreifende Konvention, deren stärkste Kontinuität eine Grenze war: Eine entfernte Seite durfte Darstellung und Namen vorschlagen. Die empfangende Seite blieb Eigentümerin der tatsächlichen Wirkung.

Quellen