1. Einführung (Introduction)
RFC 2616 definiert das Content-Disposition-Antwort-Header-Feld (Response Header Field) (Abschnitt 19.5.1 von [RFC2616]), weist aber darauf hin, dass es nicht Teil des HTTP/1.1-Standards ist (Abschnitt 15.5):
Content-Disposition ist nicht Teil des HTTP-Standards, aber da es weit verbreitet implementiert ist, dokumentieren wir seine Verwendung und Risiken für Implementierer.
Diese Spezifikation übernimmt die Definition und Registrierung von Content-Disposition, wie es in HTTP verwendet wird. Basierend auf Interoperabilitätstests mit existierenden Benutzeragenten (User Agents, UA) definiert sie vollständig ein Profil (Profile) der Funktionen, die in der Multipurpose Internet Mail Extensions (MIME)-Variante ([RFC2183]) des Header-Felds definiert sind, und klärt auch Internationalisierungsaspekte.
Hinweis: Dieses Dokument gilt nicht für Content-Disposition-Header-Felder, die in Nutzlastkörpern (Payload Body) erscheinen, die über HTTP übertragen werden, wie zum Beispiel bei Verwendung des Medientyps (Media Type) "multipart/form-data" ([RFC2388]).
2. Notationskonventionen (Notational Conventions)
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in [RFC2119] beschrieben zu interpretieren.
- MUST / MUST NOT: muss / darf nicht
- REQUIRED: erforderlich
- SHALL / SHALL NOT: muss / darf nicht
- SHOULD / SHOULD NOT: sollte / sollte nicht
- RECOMMENDED: empfohlen
- MAY: kann / darf
- OPTIONAL: optional
Diese Spezifikation verwendet die erweiterte BNF-Notation (Augmented BNF, ABNF), die in Abschnitt 2.1 von [RFC2616] definiert ist, einschließlich ihrer Regeln für impliziten linearen Leerraum (Linear Whitespace, LWS).
3. Konformität und Fehlerbehandlung (Conformance and Error Handling)
Diese Spezifikation definiert Konformitätskriterien sowohl für Sender (normalerweise HTTP-Ursprungsserver (HTTP Origin Server)) als auch für Empfänger (normalerweise HTTP-Benutzeragenten (HTTP User Agent)) des Content-Disposition-Header-Felds. Eine Implementierung gilt als konform, wenn sie allen mit ihrer Rolle verbundenen Anforderungen entspricht.
Diese Spezifikation definiert auch bestimmte Formen des Header-Feldwerts als ungültig, unter Verwendung sowohl von ABNF- als auch von Prosa-Anforderungen (Abschnitt 4), aber sie definiert keine spezielle Behandlung dieser ungültigen Feldwerte.
Sender dürfen keine ungültigen Content-Disposition-Header-Felder erzeugen (MUST NOT).
Empfänger können Maßnahmen ergreifen, um einen verwendbaren Feldwert aus einem ungültigen Header-Feld wiederherzustellen (MAY), sollten die Nachricht jedoch nicht vollständig ablehnen (SHOULD NOT), es sei denn, dies ist ausdrücklich erwünschtes Verhalten (z.B. ist die Implementierung ein Validator). Daher besteht die Standardbehandlung ungültiger Felder darin, sie zu ignorieren.