Zum Hauptinhalt springen

4. Header-Feld-Definition (Header Field Definition)

Das Content-Disposition-Antwort-Header-Feld (Response Header Field) wird verwendet, um zusätzliche Informationen darüber zu übermitteln, wie die Antwortnutzlast (Response Payload) zu verarbeiten ist, und kann auch verwendet werden, um zusätzliche Metadaten (Metadata) anzuhängen, wie zum Beispiel den Dateinamen (Filename), der beim lokalen Speichern der Antwortnutzlast verwendet werden soll.

4.1. Grammatik (Grammar)​

content-disposition = "Content-Disposition" ":"
                       disposition-type *( ";" disposition-parm )

disposition-type    = "inline" | "attachment" | disp-ext-type
                    ; Groß-/Kleinschreibung wird nicht beachtet
disp-ext-type       = token

disposition-parm    = filename-parm | disp-ext-parm

filename-parm       = "filename" "=" value
                    | "filename*" "=" ext-value

disp-ext-parm       = token "=" value
                    | ext-token "=" ext-value
ext-token           = <die Zeichen in token, gefolgt von "*">

Definiert in [RFC2616]:

token         = <token, definiert in [RFC2616], Abschnitt 2.2>
quoted-string = <quoted-string, definiert in [RFC2616], Abschnitt 2.2>
value         = <value, definiert in [RFC2616], Abschnitt 3.6>
              ; token | quoted-string

Definiert in [RFC5987]:

ext-value   = <ext-value, definiert in [RFC5987], Abschnitt 3.2>

Content-Disposition-Header-Feldwerte mit mehreren Instanzen desselben Parameternamens (Parameter Name) sind ungültig.

Beachten Sie, dass aufgrund der Regeln für impliziten linearen Leerraum (Abschnitt 2.1 von [RFC2616]) optionaler Leerraum (OPTIONAL Whitespace) zwischen Wörtern (token oder quoted-string) und Trennzeichen erscheinen kann.

Beachten Sie außerdem, dass das für ext-value verwendete Format die Angabe einer natürlichen Sprache (Natural Language) (z.B. "en") erlaubt; dies ist für Dateinamen von begrenztem Nutzen und wird wahrscheinlich von Empfängern ignoriert.

4.2. Dispositionstyp (Disposition Type)​

Wenn der Dispositionstyp (Disposition Type) "attachment" entspricht (Groß-/Kleinschreibung wird nicht beachtet), zeigt dies an, dass der Empfänger den Benutzer auffordern sollte, die Antwort lokal zu speichern, anstatt sie normal (gemäß ihrem Medientyp (Media Type)) zu verarbeiten.

Andererseits, wenn er "inline" entspricht (Groß-/Kleinschreibung wird nicht beachtet), impliziert dies die Standardverarbeitung. Daher ist der Dispositionstyp "inline" nur nützlich, wenn er mit zusätzlichen Parametern erweitert wird, wie zum Beispiel dem Dateinamen (Filename) (siehe unten).

Unbekannte oder nicht behandelte Dispositionstypen sollten von Empfängern auf dieselbe Weise wie "attachment" behandelt werden (SHOULD) (siehe auch [RFC2183], Abschnitt 2.8).

4.3. Dispositionsparameter: Dateiname (Disposition Parameter: 'Filename')​

Die Parameter (Parameter) "filename" und "filename*" (Übereinstimmung ohne Beachtung der Groß-/Kleinschreibung) liefern Informationen darüber, wie ein Dateiname zum Speichern der Nachrichtennutzlast (Message Payload) konstruiert werden soll.

Je nach Dispositionstyp können diese Informationen sofort verwendet werden (in der "Speichern unter..."-Interaktion, die durch den Dispositionstyp "attachment" verursacht wird), oder später (zum Beispiel, wenn der Benutzer beschließt, den Inhalt der aktuell angezeigten Seite zu speichern).

Die Parameter "filename" und "filename*" unterscheiden sich nur dadurch, dass "filename*" die in [RFC5987] definierte Kodierung (Encoding) verwendet, die die Verwendung von Zeichen ermöglicht, die nicht im ISO-8859-1-Zeichensatz (Character Set) ([ISO-8859-1]) vorhanden sind.

Viele Benutzeragenten-Implementierungen (User Agent), die dieser Spezifikation vorausgehen, verstehen den Parameter "filename*" nicht. Daher sollten Empfänger, wenn sowohl "filename" als auch "filename*" in einem einzigen Header-Feldwert vorhanden sind, "filename*" wählen und "filename" ignorieren (SHOULD). Auf diese Weise können Sender spezielle Behandlungen für bestimmte Benutzeragenten vermeiden, indem sie sowohl den ausdrucksstärkeren Parameter "filename*" als auch den Parameter "filename" als Fallback (Fallback) für ältere Empfänger senden (siehe Abschnitt 5 für ein Beispiel).

Es ist wesentlich, dass Empfänger den angegebenen Dateinamen nur als Empfehlung behandeln und daher bei der Extraktion der gewünschten Informationen sehr vorsichtig sind. Insbesondere:

  • Empfänger dürfen nicht in der Lage sein, an einen anderen Ort als denjenigen zu schreiben, zu dem sie speziell berechtigt sind (MUST NOT). Um das Problem zu veranschaulichen, betrachten Sie die Konsequenzen der Möglichkeit, bekannte Systemspeicherorte (wie "/etc/passwd") zu überschreiben. Eine Strategie, dies zu erreichen, besteht darin, niemals Ordnernameinformationen im filename-Parameter zu vertrauen, zum Beispiel indem alle bis auf das letzte Pfadsegment (Path Segment) entfernt werden und nur der tatsächliche Dateiname berücksichtigt wird (wobei "Pfadsegmente" die Komponenten des Feldwerts sind, die durch die Pfadtrennzeichen (Path Separator Character) "\" und "/" getrennt sind).

  • Viele Plattformen verwenden keine Internet-Medientypen (Internet Media Type) ([RFC2046]), um Typinformationen im Dateisystem (File System) zu speichern, sondern verlassen sich stattdessen auf Dateinamenerweiterungen (Filename Extension). Das Vertrauen in die vom Server bereitgestellte Dateierweiterung könnte eine Rechteausweitung (Privilege Escalation) einführen, wenn die gespeicherte Datei später geöffnet wird (betrachten Sie ".exe"). Daher müssen Empfänger, die Dateierweiterungen verwenden, um den Medientyp zu bestimmen, sicherstellen, dass eine verwendete Dateierweiterung sicher ist und optimal mit dem Medientyp der empfangenen Nutzlast übereinstimmt (MUST).

  • Empfänger sollten Zeichensequenzen (Character Sequence) entfernen oder ersetzen, von denen bekannt ist, dass sie sowohl in Benutzeroberflächen (User Interface) als auch in Dateinamen Verwirrung stiften, wie Steuerzeichen (Control Character) sowie führende und nachgestellte Leerzeichen (SHOULD).

  • Andere Aspekte, derer sich Empfänger bewusst sein müssen, sind Namen, die eine besondere Bedeutung im Dateisystem oder in Shell-Befehlen (Shell Command) haben, wie "." und "..", "~", "|" sowie Gerätenamen (Device Name). Empfänger sollten solche Namen ignorieren oder ersetzen (SHOULD).

Hinweis: Viele Benutzeragenten behandeln das Escape-Zeichen (Escape Character) "\" bei Verwendung der quoted-string-Form nicht ordnungsgemäß. Darüber hinaus versuchen einige Benutzeragenten fälschlicherweise, "Prozent"-Escapes (Percent Escape) zu decodieren (siehe Anhang C.2), und können daher Dateinamen, die das Prozentzeichen gefolgt von zwei Hexadezimalziffern enthalten, falsch interpretieren.

4.4. Dispositionsparameter: Erweiterungen (Disposition Parameter: Extensions)​

Um zukünftige Erweiterungen zu ermöglichen, sollten Empfänger nicht erkannte Parameter ignorieren (SHOULD) (siehe auch [RFC2183], Abschnitt 2.8).

4.5. Erweiterbarkeit (Extensibility)​

Beachten Sie, dass Abschnitt 9 von [RFC2183] IANA-Register (IANA Registry) sowohl für Dispositionswerte (Disposition Value) als auch für Dispositionsparameter (Disposition Parameter) definiert. Dieses Register wird von verschiedenen Protokollen (Protocol), die Content-Disposition verwenden, wie MIME und HTTP, gemeinsam genutzt. Daher haben nicht alle registrierten Werte im Kontext von HTTP Bedeutung.

Letztes Update am