Appendix A. Differences between HTTP and MIME (Différences entre HTTP et MIME)
HTTP/1.1 utilise de nombreuses constructions définies pour le format de message Internet [RFC5322] et les extensions de messagerie Internet multi-usages (MIME) [RFC2045] pour permettre la transmission d'un corps de message dans une variété ouverte de représentations et avec des champs d'en-tête extensibles. Cependant, RFC 2045 se concentre uniquement sur le courrier électronique; les applications HTTP présentent de nombreuses caractéristiques différentes du courrier électronique; par conséquent, HTTP possède des fonctionnalités qui diffèrent de MIME. Ces différences ont été soigneusement choisies pour optimiser les performances sur les connexions binaires, permettre une plus grande liberté dans l'utilisation de nouveaux types de médias, faciliter les comparaisons de dates et reconnaître la pratique de certains serveurs et clients HTTP précoces.
Cette annexe décrit les domaines spécifiques où HTTP diffère de MIME. Les proxys et les passerelles vers et depuis des environnements MIME stricts doivent être conscients de ces différences et fournir les conversions appropriées si nécessaire.
A.1. MIME-Version
HTTP n'est pas un protocole conforme à MIME. Cependant, les messages peuvent inclure un seul champ d'en-tête MIME-Version pour indiquer quelle version du protocole MIME a été utilisée pour construire le message. L'utilisation du champ d'en-tête MIME-Version indique que le message est en pleine conformité avec le protocole MIME (tel que défini dans [RFC2045]). Les expéditeurs sont responsables d'assurer la pleine conformité (lorsque cela est possible) lors de l'exportation de messages HTTP vers des environnements MIME stricts.
A.2. Conversion to Canonical Form (Conversion en forme canonique)
MIME exige qu'une partie du corps de messagerie Internet soit convertie en forme canonique avant d'être transférée, comme décrit dans la section 4 de [RFC2049]. La section 3.1.1.3 de ce document décrit les formes autorisées pour les sous-types du type de média "text" lorsqu'ils sont transmis via HTTP. [RFC2046] exige que le contenu de type "text" représente les sauts de ligne sous forme de CRLF et interdit l'utilisation de CR ou LF en dehors des séquences de saut de ligne. HTTP permet CRLF, CR seul et LF seul pour indiquer un saut de ligne dans le contenu textuel.
Un proxy ou une passerelle de HTTP vers un environnement MIME strict devrait traduire tous les sauts de ligne dans les types de médias texte décrits dans la section 3.1.1.3 de ce document vers la forme canonique RFC 2049 de CRLF. Notez cependant que cela peut être compliqué par la présence d'un Content-Encoding et par le fait que HTTP permet l'utilisation de certains jeux de caractères qui n'utilisent pas les octets 13 et 10 pour représenter respectivement CR et LF.
La conversion brisera toutes les sommes de contrôle cryptographiques appliquées au contenu original à moins que le contenu original ne soit déjà sous forme canonique. Par conséquent, la forme canonique est recommandée pour tout contenu utilisant de telles sommes de contrôle dans HTTP.
A.3. Conversion of Date Formats (Conversion des formats de date)
HTTP/1.1 utilise un ensemble restreint de formats de date (section 7.1.1.1) pour simplifier le processus de comparaison de dates. Les proxys et les passerelles d'autres protocoles devraient s'assurer que tout champ d'en-tête Date présent dans un message est conforme à l'un des formats HTTP/1.1 et réécrire la date si nécessaire.
A.4. Conversion of Content-Encoding (Conversion du Content-Encoding)
MIME n'inclut aucun concept équivalent au champ d'en-tête Content-Encoding de HTTP/1.1. Puisque cela agit comme un modificateur du type de média, les proxys et les passerelles de HTTP vers les protocoles conformes à MIME devraient soit changer la valeur du champ d'en-tête Content-Type, soit décoder la représentation avant de transférer le message. (Certaines applications expérimentales de Content-Type pour le courrier Internet ont utilisé un paramètre de type de média de ";conversions=<content-coding>" pour effectuer une fonction équivalente à Content-Encoding. Cependant, ce paramètre ne fait pas partie des normes MIME).
A.5. Conversion of Content-Transfer-Encoding (Conversion du Content-Transfer-Encoding)
HTTP n'utilise pas le champ Content-Transfer-Encoding de MIME. Les proxys et les passerelles des protocoles conformes à MIME vers HTTP doivent supprimer tout Content-Transfer-Encoding avant de délivrer le message de réponse à un client HTTP.
Les proxys et les passerelles de HTTP vers les protocoles conformes à MIME sont responsables de s'assurer que le message est dans le format et l'encodage corrects pour un transport sûr sur ce protocole, où "transport sûr" est défini par les limitations du protocole utilisé. De tels proxys ou passerelles devraient transformer et étiqueter les données avec un Content-Transfer-Encoding approprié si cela améliore la probabilité de transport sûr sur le protocole de destination.
A.6. MHTML and Line Length Limitations (MHTML et limitations de longueur de ligne)
Les implémentations HTTP qui partagent du code avec les implémentations MHTML [RFC2557] doivent être conscientes des limitations de longueur de ligne MIME. Puisque HTTP n'a pas cette limitation, HTTP ne plie pas les longues lignes. Les messages MHTML transportés via HTTP suivent toutes les conventions de MHTML, y compris les limitations et pliages de longueur de ligne, la canonicalisation, etc., car HTTP transporte tous les corps de message en tant que charge utile et, à l'exception du type "multipart/byteranges" (annexe A de [RFC7233]), n'interprète pas le contenu ou les lignes d'en-tête MIME qui pourraient y être contenues.