4. Définition du champ d'en-tête (Header Field Definition)

Le champ d'en-tête de réponse (Response Header Field) Content-Disposition est utilisé pour transmettre des informations supplémentaires sur la manière de traiter la charge utile de réponse (Response Payload), et peut également être utilisé pour attacher des métadonnées (Metadata) supplémentaires, telles que le nom de fichier (Filename) à utiliser lors de l'enregistrement local de la charge utile de réponse.

4.1. Grammaire (Grammar)

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

disposition-type    = "inline" | "attachment" | disp-ext-type
                    ; insensible à la casse
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           = <les caractères dans token, suivis de "*">

Défini dans [RFC2616] :

token         = <token, défini dans [RFC2616], Section 2.2>
quoted-string = <quoted-string, défini dans [RFC2616], Section 2.2>
value         = <value, défini dans [RFC2616], Section 3.6>
              ; token | quoted-string

Défini dans [RFC5987] :

ext-value   = <ext-value, défini dans [RFC5987], Section 3.2>

Les valeurs de champ d'en-tête Content-Disposition avec plusieurs instances du même nom de paramètre (Parameter Name) sont invalides.

Notez qu'en raison des règles d'espacement linéaire implicite (Section 2.1 de [RFC2616]), un espacement optionnel (OPTIONAL Whitespace) peut apparaître entre les mots (mot) (token ou quoted-string) et les caractères de séparation.

De plus, notez que le format utilisé pour ext-value permet de spécifier une langue naturelle (Natural Language) (par exemple, "en") ; ceci est d'une utilité limitée pour les noms de fichiers et est susceptible d'être ignoré par les destinataires.

4.2. Type de disposition (Disposition Type)

Si le type de disposition (Disposition Type) correspond à "attachment" (insensible à la casse), cela indique que le destinataire devrait inviter l'utilisateur à enregistrer la réponse localement, plutôt que de la traiter normalement (selon son type de média (Media Type)).

D'autre part, s'il correspond à "inline" (insensible à la casse), cela implique un traitement par défaut. Par conséquent, le type de disposition "inline" n'est utile que lorsqu'il est augmenté avec des paramètres supplémentaires, tels que le nom de fichier (Filename) (voir ci-dessous).

Les types de disposition inconnus ou non gérés devraient être traités par les destinataires de la même manière que "attachment" (SHOULD) (voir également [RFC2183], Section 2.8).

4.3. Paramètre de disposition : Nom de fichier (Disposition Parameter: 'Filename')

Les paramètres (Parameter) "filename" et "filename*" (correspondance insensible à la casse) fournissent des informations sur la manière de construire un nom de fichier pour stocker la charge utile du message (Message Payload).

Selon le type de disposition, ces informations peuvent être utilisées immédiatement (dans l'interaction « Enregistrer sous... » causée par le type de disposition "attachment"), ou ultérieurement (par exemple, lorsque l'utilisateur décide d'enregistrer le contenu de la page actuellement affichée).

Les paramètres "filename" et "filename*" ne diffèrent que par le fait que "filename*" utilise l'encodage (Encoding) défini dans [RFC5987], permettant l'utilisation de caractères non présents dans le jeu de caractères (Character Set) ISO-8859-1 ([ISO-8859-1]).

De nombreuses implémentations d'agents utilisateurs (User Agent) antérieures à cette spécification ne comprennent pas le paramètre "filename*". Par conséquent, lorsque "filename" et "filename*" sont tous deux présents dans une seule valeur de champ d'en-tête, les destinataires devraient choisir "filename*" et ignorer "filename" (SHOULD). De cette façon, les expéditeurs peuvent éviter un traitement spécial pour des agents utilisateurs spécifiques en envoyant à la fois le paramètre "filename*" plus expressif et le paramètre "filename" comme solution de repli (Fallback) pour les destinataires hérités (voir Section 5 pour un exemple).

Il est essentiel que les destinataires traitent le nom de fichier spécifié comme un conseil uniquement, et soient donc très prudents dans l'extraction des informations souhaitées. En particulier :

• Les destinataires ne doivent pas pouvoir écrire dans un emplacement autre que celui auquel ils sont spécifiquement autorisés (MUST NOT). Pour illustrer le problème, considérez les conséquences de pouvoir écraser des emplacements système bien connus (tels que "/etc/passwd"). Une stratégie pour y parvenir consiste à ne jamais faire confiance aux informations de nom de dossier dans le paramètre filename, par exemple en supprimant tout sauf le dernier segment de chemin (Path Segment) et en ne considérant que le nom de fichier réel (où les « segments de chemin » sont les composants de la valeur de champ délimités par les caractères de séparation de chemin (Path Separator Character) "\" et "/").

• De nombreuses plateformes n'utilisent pas les types de média Internet (Internet Media Type) ([RFC2046]) pour conserver les informations de type dans le système de fichiers (File System), mais s'appuient plutôt sur les extensions de nom de fichier (Filename Extension). Faire confiance à l'extension de fichier fournie par le serveur pourrait introduire une escalade de privilèges (Privilege Escalation) lorsque le fichier enregistré est ouvert ultérieurement (considérez ".exe"). Ainsi, les destinataires qui utilisent les extensions de fichier pour déterminer le type de média doivent s'assurer qu'une extension de fichier utilisée est sûre, correspondant de manière optimale au type de média de la charge utile reçue (MUST).

• Les destinataires devraient supprimer ou remplacer les séquences de caractères (Character Sequence) connues pour causer de la confusion dans les interfaces utilisateur (User Interface) et dans les noms de fichiers, telles que les caractères de contrôle (Control Character) ainsi que les espaces de début et de fin (SHOULD).

• D'autres aspects dont les destinataires doivent être conscients sont les noms qui ont une signification spéciale dans le système de fichiers ou dans les commandes shell (Shell Command), tels que "." et "..", "~", "|", ainsi que les noms de périphériques (Device Name). Les destinataires devraient ignorer ou substituer de tels noms (SHOULD).

Note : De nombreux agents utilisateurs ne gèrent pas correctement le caractère d'échappement (Escape Character) "\" lors de l'utilisation de la forme quoted-string. De plus, certains agents utilisateurs tentent par erreur d'effectuer un désé­chappement des échappements « pour cent » (Percent Escape) (voir Annexe C.2), et peuvent donc mal interpréter les noms de fichiers contenant le caractère pour cent suivi de deux chiffres hexadécimaux.

4.4. Paramètre de disposition : Extensions (Disposition Parameter: Extensions)

Pour permettre de futures extensions, les destinataires devraient ignorer les paramètres non reconnus (SHOULD) (voir également [RFC2183], Section 2.8).

4.5. Extensibilité (Extensibility)

Notez que la Section 9 de [RFC2183] définit des registres IANA (IANA Registry) à la fois pour les valeurs de disposition (Disposition Value) et les paramètres de disposition (Disposition Parameter). Ce registre est partagé par différents protocoles (Protocol) utilisant Content-Disposition, tels que MIME et HTTP. Par conséquent, toutes les valeurs enregistrées n'ont pas nécessairement de sens dans le contexte de HTTP.