Anhang A. Änderungen gegenüber der RFC 2616-Definition (Changes from the RFC 2616 Definition)

Im Vergleich zu Abschnitt 19.5.1 von [RFC2616] wurden die folgenden normativen Änderungen vorgenommen, die tatsächliche Implementierungen widerspiegeln:

• Gemäß RFC 2616 gilt der Dispositionstyp (Disposition Type) "attachment" nur für Inhalte vom Typ "application/octet-stream". Diese Einschränkung wurde entfernt, da Empfänger in der Praxis den Inhaltstyp (Content Type) nicht überprüfen und dies auch die ordnungsgemäße Deklaration des Medientyps (Media Type) behindert.

• RFC 2616 erlaubt nur "quoted-string" für den filename-Parameter. Dies wäre eine außergewöhnliche Parametersyntax und spiegelt auch nicht die tatsächliche Verwendung wider.

• Die Definition für den Dispositionstyp "inline" ([RFC2183], Abschnitt 2.1) wurde mit einem Vorschlag für seine Verarbeitung wieder hinzugefügt.

• Diese Spezifikation erfordert (REQUIRED) die Unterstützung der in [RFC5987] definierten erweiterten Parameterkodierung (Extended Parameter Encoding).

Anhang B. Unterschiede zu RFC 2183 (Differences Compared to RFC 2183)

Abschnitt 2 von [RFC2183] definiert mehrere zusätzliche Dispositionsparameter (Disposition Parameter): "creation-date", "modification-date", "quoted-date-time" und "size". Die Mehrheit der Benutzeragenten (User Agent) implementiert diese nicht; daher wurden sie aus dieser Spezifikation weggelassen.

Anhang C. Alternative Ansätze zur Internationalisierung (Alternative Approaches to Internationalization)

Standardmäßig können HTTP-Header-Feld-Parameter (HTTP Header Field Parameter) keine Zeichen außerhalb der ISO-8859-1-Zeichenkodierung (Character Encoding) ([ISO-8859-1]) tragen (siehe [RFC2616], Abschnitt 2.2). Für den Parameter "filename" ist dies natürlich eine inakzeptable Einschränkung.

Leider ist es Benutzeragenten-Implementierern nicht gelungen, einen interoperablen Ansatz zu entwickeln, obwohl der IETF Standards Track genau eine Lösung spezifiziert ([RFC2231], für HTTP in [RFC5987] geklärt und profiliert).

Der Vollständigkeit halber beschreiben die folgenden Abschnitte die verschiedenen Ansätze, die versucht wurden, und erklären, warum sie der in dieser Spezifikation verwendeten RFC 5987-Kodierung (Encoding) unterlegen sind.

C.1. RFC 2047-Kodierung (RFC 2047 Encoding)

RFC 2047 definiert einen Kodierungsmechanismus (Encoding Mechanism) für Header-Felder (Header Field), aber diese Kodierung soll nicht für Header-Feld-Parameter verwendet werden -- siehe Abschnitt 5 von [RFC2047]:

Ein 'encoded-word' darf nicht innerhalb eines 'quoted-string' erscheinen (MUST NOT).

...

Ein 'encoded-word' darf nicht in einem Parameter eines MIME Content-Type- oder Content-Disposition-Felds oder in einem strukturierten Feldkörper verwendet werden, außer innerhalb eines 'comment' oder einer 'phrase' (MUST NOT).

In der Praxis implementieren einige Benutzeragenten die Kodierung, einige nicht (wodurch die kodierte Zeichenkette dem Benutzer angezeigt wird), und einige werden dadurch verwirrt.

C.2. Prozent-Kodierung (Percent Encoding)

Einige Benutzeragenten akzeptieren prozentkodierte ([RFC3986], Abschnitt 2.1) Zeichensequenzen (Character Sequence). Die für die Dekodierung verwendete Zeichenkodierung hängt von verschiedenen Faktoren ab, einschließlich der Kodierung der verweisenden Seite, der Locale (Locale) des Benutzeragenten, seiner Konfiguration sowie dem tatsächlichen Wert des Parameters.

In der Praxis ist dies schwer zu verwenden, da Benutzeragenten, die dies nicht unterstützen, die escapte Zeichensequenz dem Benutzer anzeigen. Für diejenigen, die dies implementieren, ist es schwierig vorherzusagen, welche Zeichenkodierung sie tatsächlich erwarten.

C.3. Kodierungs-Sniffing (Encoding Sniffing)

Einige Benutzeragenten untersuchen den Wert (der standardmäßig ISO-8859-1 für die quoted-string-Form ist) und wechseln zu UTF-8, wenn es wahrscheinlicher erscheint, die richtige Interpretation zu sein.

Wie bei den obigen Ansätzen ist dies nicht interoperabel und birgt außerdem das Risiko, den tatsächlichen Wert falsch zu interpretieren.

Anhang D. Ratschläge zur Generierung von Content-Disposition-Header-Feldern (Advice on Generating Content-Disposition Header Fields)

Um mit existierenden und zukünftigen Benutzeragenten (User Agent) erfolgreich interoperieren zu können, wird Sendern des Content-Disposition-Header-Felds (Header Field) geraten:

• Einen Parameter "filename" einzuschließen, wenn US-ASCII ([US-ASCII]) ausreichend ausdrucksstark ist.

• Die 'token'-Form des filename-Parameters nur zu verwenden, wenn sie keine unzulässigen Zeichen enthält (z.B. Leerzeichen); in solchen Fällen sollte die quoted-string-Form verwendet werden.

• Das Prozentzeichen gefolgt von zwei Hexadezimalzeichen (z.B. %A9) im filename-Parameter zu vermeiden, da einige existierende Implementierungen dies als Escape-Zeichen (Escape Character) betrachten, während andere es unverändert weitergeben.

• Das Zeichen "\" in der quoted-string-Form des filename-Parameters zu vermeiden, da Escaping von einigen Benutzeragenten nicht implementiert wird und "\" als illegales Pfadzeichen (Path Character) betrachtet werden kann.

• Die Verwendung von Nicht-ASCII-Zeichen im filename-Parameter zu vermeiden. Obwohl die meisten existierenden Implementierungen sie als ISO-8859-1 dekodieren, wenden einige Heuristiken (Heuristic) an, um UTF-8 zu erkennen, und können daher bei bestimmten Namen fehlschlagen.

• Einen Parameter "filename*" einzuschließen, wenn der gewünschte Dateiname nicht getreu mit der "filename"-Form ausgedrückt werden kann. Beachten Sie, dass ältere Benutzeragenten (Legacy User Agent) dies nicht verarbeiten und auf die Verwendung des Inhalts des "filename"-Parameters zurückgreifen werden.

• Wenn ein Parameter "filename*" gesendet wird, auch einen Parameter "filename" als Fallback (Fallback) für Benutzeragenten zu generieren, die die "filename*"-Form nicht unterstützen, falls möglich. Dies kann durch Ersetzen von Zeichen durch US-ASCII-Sequenzen erfolgen (z.B. Unicode-Zeichenpunkt U+00E4 (LATEINISCHER KLEINBUCHSTABE A MIT TREMA) durch "ae"). Beachten Sie, dass dies in einigen Locales möglicherweise nicht möglich ist.

• Wenn ein Parameter "filename" als Fallback eingeschlossen ist (wie oben), sollte "filename" aufgrund von Parsing-Problemen in einigen existierenden Implementierungen zuerst erscheinen.

• UTF-8 als Kodierung des Parameters "filename*" zu verwenden, wenn vorhanden, da mindestens eine existierende Implementierung nur diese Kodierung implementiert.

Hinweis: Dieser Rat basiert auf dem Verhalten von Benutzeragenten (UA) zum Zeitpunkt des Schreibens und könnte ersetzt werden. Zum Zeitpunkt der Veröffentlichung dieses Dokuments bietet http://purl.org/NET/http/content-disposition-tests einen Überblick über aktuelle Unterstützungsstufen in verschiedenen Implementierungen.