Annexe A. Modifications par rapport à la définition RFC 2616 (Changes from the RFC 2616 Definition)

Par rapport à la Section 19.5.1 de [RFC2616], les modifications normatives suivantes reflétant les implémentations réelles ont été apportées :

• Selon RFC 2616, le type de disposition (Disposition Type) "attachment" ne s'applique qu'au contenu de type "application/octet-stream". Cette restriction a été supprimée, car les destinataires ne vérifient pas le type de contenu (Content Type) en pratique, et cela décourage également de déclarer correctement le type de média (Media Type).

• La RFC 2616 n'autorise que "quoted-string" pour le paramètre filename. Cela constituerait une syntaxe de paramètre exceptionnelle et ne reflète pas non plus l'utilisation réelle.

• La définition du type de disposition "inline" ([RFC2183], Section 2.1) a été réajoutée avec une suggestion pour son traitement.

• Cette spécification requiert (REQUIRED) la prise en charge de l'encodage de paramètres étendu (Extended Parameter Encoding) défini dans [RFC5987].

Annexe B. Différences par rapport à RFC 2183 (Differences Compared to RFC 2183)

La Section 2 de [RFC2183] définit plusieurs paramètres de disposition (Disposition Parameter) supplémentaires : "creation-date", "modification-date", "quoted-date-time" et "size". La majorité des agents utilisateurs (User Agent) ne les implémentent pas ; ils ont donc été omis de cette spécification.

Annexe C. Approches alternatives pour l'internationalisation (Alternative Approaches to Internationalization)

Par défaut, les paramètres de champ d'en-tête HTTP (HTTP Header Field Parameter) ne peuvent pas transporter de caractères en dehors de l'encodage de caractères (Character Encoding) ISO-8859-1 ([ISO-8859-1]) (voir [RFC2616], Section 2.2). Pour le paramètre "filename", ceci est bien sûr une restriction inacceptable.

Malheureusement, les implémenteurs d'agents utilisateurs n'ont pas réussi à proposer une approche interopérable, bien que la piste de normalisation IETF (IETF Standards Track) spécifie exactement une solution ([RFC2231], clarifiée et profilée pour HTTP dans [RFC5987]).

Pour être complet, les sections ci-dessous décrivent les différentes approches qui ont été essayées, et expliquent en quoi elles sont inférieures à l'encodage (Encoding) RFC 5987 utilisé dans cette spécification.

C.1. Encodage RFC 2047 (RFC 2047 Encoding)

La RFC 2047 définit un mécanisme d'encodage (Encoding Mechanism) pour les champs d'en-tête (Header Field), mais cet encodage n'est pas censé être utilisé pour les paramètres de champ d'en-tête -- voir Section 5 de [RFC2047] :

Un 'encoded-word' ne doit pas apparaître dans un 'quoted-string' (MUST NOT).

...

Un 'encoded-word' ne doit pas être utilisé dans un paramètre d'un champ MIME Content-Type ou Content-Disposition, ou dans tout corps de champ structuré sauf dans un 'comment' ou une 'phrase' (MUST NOT).

En pratique, certains agents utilisateurs implémentent l'encodage, certains ne le font pas (exposant la chaîne encodée à l'utilisateur), et certains sont confus par celui-ci.

C.2. Encodage en pourcentage (Percent Encoding)

Certains agents utilisateurs acceptent des séquences de caractères (Character Sequence) encodées en pourcentage ([RFC3986], Section 2.1). L'encodage de caractères utilisé pour le décodage dépend de divers facteurs, y compris l'encodage de la page de référence, la locale (Locale) de l'agent utilisateur, sa configuration, ainsi que la valeur réelle du paramètre.

En pratique, ceci est difficile à utiliser car les agents utilisateurs qui ne le prennent pas en charge afficheront la séquence de caractères échappés à l'utilisateur. Pour ceux qui implémentent cela, il est difficile de prédire quel encodage de caractères ils attendent réellement.

C.3. Détection d'encodage (Encoding Sniffing)

Certains agents utilisateurs inspectent la valeur (qui par défaut est ISO-8859-1 pour la forme quoted-string) et basculent vers UTF-8 lorsqu'il semble plus probable que ce soit l'interprétation correcte.

Comme avec les approches ci-dessus, ceci n'est pas interopérable et, de plus, risque de mal interpréter la valeur réelle.

Annexe D. Conseils pour générer les champs d'en-tête Content-Disposition (Advice on Generating Content-Disposition Header Fields)

Pour interopérer avec succès avec les agents utilisateurs (User Agent) existants et futurs, il est conseillé aux expéditeurs du champ d'en-tête (Header Field) Content-Disposition de :

• Inclure un paramètre "filename" lorsque US-ASCII ([US-ASCII]) est suffisamment expressif.

• Utiliser la forme 'token' du paramètre filename uniquement lorsqu'il ne contient pas de caractères interdits (par exemple, des espaces) ; dans de tels cas, la forme quoted-string devrait être utilisée.

• Éviter d'inclure le caractère pour cent suivi de deux caractères hexadécimaux (par exemple, %A9) dans le paramètre filename, car certaines implémentations existantes le considèrent comme un caractère d'échappement (Escape Character), tandis que d'autres le laissent passer inchangé.

• Éviter d'inclure le caractère "\" dans la forme quoted-string du paramètre filename, car l'échappement n'est pas implémenté par certains agents utilisateurs, et "\" peut être considéré comme un caractère de chemin (Path Character) illégal.

• Éviter d'utiliser des caractères non-ASCII dans le paramètre filename. Bien que la plupart des implémentations existantes les décodent en ISO-8859-1, certaines appliquent des heuristiques (Heuristic) pour détecter UTF-8, et peuvent donc échouer sur certains noms.

• Inclure un paramètre "filename*" lorsque le nom de fichier souhaité ne peut pas être exprimé fidèlement en utilisant la forme "filename". Notez que les agents utilisateurs hérités (Legacy User Agent) ne traiteront pas ceci et se replieront sur l'utilisation du contenu du paramètre "filename".

• Lorsqu'un paramètre "filename*" est envoyé, générer également un paramètre "filename" comme solution de repli (Fallback) pour les agents utilisateurs qui ne prennent pas en charge la forme "filename*", si possible. Cela peut être fait en substituant les caractères par des séquences US-ASCII (par exemple, le point de code Unicode (Unicode Character Point) U+00E4 (LETTRE MINUSCULE LATINE A AVEC TRÉMA) par "ae"). Notez que cela peut ne pas être possible dans certaines locales.

• Lorsqu'un paramètre "filename" est inclus comme solution de repli (comme ci-dessus), "filename" devrait apparaître en premier, en raison de problèmes d'analyse dans certaines implémentations existantes.

• Utiliser UTF-8 comme encodage du paramètre "filename*", lorsqu'il est présent, car au moins une implémentation existante n'implémente que cet encodage.

Note : Ce conseil est basé sur le comportement des agents utilisateurs (UA) au moment de la rédaction et pourrait être remplacé. Au moment de la publication de ce document, http://purl.org/NET/http/content-disposition-tests fournit un aperçu des niveaux de support actuels dans diverses implémentations.