1. Introduction
La RFC 2616 définit le champ d'en-tête de réponse (Response Header Field) Content-Disposition (Section 19.5.1 de [RFC2616]) mais souligne qu'il ne fait pas partie de la norme HTTP/1.1 (Section 15.5) :
Content-Disposition ne fait pas partie de la norme HTTP, mais comme il est largement implémenté, nous documentons son utilisation et les risques pour les implémenteurs.
Cette spécification reprend la définition et l'enregistrement de Content-Disposition, tel qu'utilisé dans HTTP. Sur la base de tests d'interopérabilité avec les agents utilisateurs (User Agents, UA) existants, elle définit complètement un profil (Profile) des fonctionnalités définies dans la variante Multipurpose Internet Mail Extensions (MIME) ([RFC2183]) du champ d'en-tête, et clarifie également les aspects d'internationalisation.
Note : Ce document ne s'applique pas aux champs d'en-tête Content-Disposition apparaissant dans les corps de charge utile (Payload Body) transmis via HTTP, par exemple lors de l'utilisation du type de média (Media Type) "multipart/form-data" ([RFC2388]).
2. Conventions de notation (Notational Conventions)
Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119].
- MUST / MUST NOT : doit / ne doit pas
- REQUIRED : requis / obligatoire
- SHALL / SHALL NOT : doit / ne doit pas
- SHOULD / SHOULD NOT : devrait / ne devrait pas
- RECOMMENDED : recommandé
- MAY : peut
- OPTIONAL : optionnel
Cette spécification utilise la notation BNF augmentée (Augmented BNF, ABNF) définie dans la Section 2.1 de [RFC2616], y compris ses règles pour les espaces linéaires implicites (Linear Whitespace, LWS).
3. Conformité et gestion des erreurs (Conformance and Error Handling)
Cette spécification définit des critères de conformité pour les expéditeurs (généralement, les serveurs d'origine HTTP (HTTP Origin Server)) et les destinataires (généralement, les agents utilisateurs HTTP (HTTP User Agent)) du champ d'en-tête Content-Disposition. Une implémentation est considérée comme conforme si elle se conforme à toutes les exigences associées à son rôle.
Cette spécification définit également certaines formes de valeur de champ d'en-tête comme invalides, en utilisant à la fois des exigences ABNF et en prose (Section 4), mais elle ne définit pas de traitement spécial de ces valeurs de champ invalides.
Les expéditeurs ne doivent pas générer de champs d'en-tête Content-Disposition invalides (MUST NOT).
Les destinataires peuvent prendre des mesures pour récupérer une valeur de champ utilisable à partir d'un champ d'en-tête invalide (MAY), mais ne devraient pas rejeter complètement le message (SHOULD NOT), sauf si c'est un comportement explicitement souhaité (par exemple, l'implémentation est un validateur (Validator)). Ainsi, le traitement par défaut des champs invalides est de les ignorer.