17. References (Références)
17 Références
Les références ci-dessous conservent les informations bibliographiques du RFC original. Afin de ne pas nuire à l'exactitude des citations, les noms d'auteurs, les titres des documents, les numéros de RFC, les informations de publication et les URL sont conservés dans leur forme originale en anglais.
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC 1630, June 1994.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1123, October 1989.
[9] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype Functional Specification," (v1.5), Thinking Machines Corporation, April 1990.
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[20] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[22] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, (original report dated Aug. 1996), USC/Information Sciences Institute, August 1998.
[28] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[30] S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html.
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[35] Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO-10646", RFC 2279, January 1998. [jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes France, September 1997.[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998. [jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers," Work in Progress. [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
18 Adresses des auteurs (Authors' Addresses)
Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA
Fax: +1 (949) 824-1715 EMail: [email protected]
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA
EMail: [email protected]
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA
EMail: [email protected]
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
EMail: [email protected]
Tim Berners-Lee Director, World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
19 Annexes (Appendices)
19.1 Internet Media Type message/http and application/http (Types de médias Internet message/http et application/http)
En plus de définir le protocole HTTP/1.1, ce document sert de spécification pour les types de médias Internet "message/http" et "application/http". Le type message/http peut être utilisé pour encapsuler un message de requête ou de réponse HTTP unique, à condition qu'il respecte les restrictions MIME applicables à tous les types "message" en matière de longueur de ligne et d'encodage. Le type application/http peut être utilisé pour encapsuler un pipeline d'un ou plusieurs messages de requête ou de réponse HTTP (non entremêlés). Ce qui suit doit être enregistré auprès de l'IANA [17].
Media Type name: message
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Media Type name: application
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed messages
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: HTTP messages enclosed by this type
are in "binary" format; use of an appropriate
Content-Transfer-Encoding is required when
transmitted via E-mail.
Security considerations: none
19.2 Internet Media Type multipart/byteranges (Type de média Internet multipart/byteranges)
Lorsqu'un message de réponse HTTP 206 (Partial Content) inclut le contenu de plusieurs plages (une réponse à une requête portant sur plusieurs plages non chevauchantes), celles-ci sont transmises sous la forme d'un corps de message multipartite. Le type de média utilisé à cette fin est appelé "multipart/byteranges".
Le type de média multipart/byteranges comprend deux parties ou plus, chacune possédant ses propres champs Content-Type et Content-Range. Le paramètre boundary requis spécifie la chaîne de délimitation utilisée pour séparer chaque partie du corps.
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Par exemple :
HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
Notes :
1) Des CRLF supplémentaires peuvent précéder la première chaîne de
délimitation dans l'entité.
2) Bien que le RFC 2046 [40] autorise la mise entre guillemets de
la chaîne de délimitation, certaines implémentations existantes
traitent incorrectement une chaîne de délimitation entre
guillemets.
3) Un certain nombre de navigateurs et de serveurs ont été codés
d'après une première version préliminaire de la spécification
byteranges et utilisent un type de média
multipart/x-byteranges, qui est presque, mais pas tout à fait,
compatible avec la version documentée dans HTTP/1.1.
19.3 Tolerant Applications (Applications tolérantes)
Bien que ce document spécifie les exigences relatives à la génération des messages HTTP/1.1, toutes les applications ne seront pas correctes dans leur implémentation. Nous recommandons donc que les applications opérationnelles soient tolérantes aux écarts chaque fois que ces écarts peuvent être interprétés sans ambiguïté.
Les clients DEVRAIENT être tolérants lors de l'analyse de la Status-Line et les serveurs tolérants lors de l'analyse de la Request-Line. En particulier, ils DEVRAIENT accepter un nombre quelconque de caractères SP ou HT entre les champs, même si un seul SP est requis.
Le terminateur de ligne des champs d'en-tête de message est la séquence CRLF. Cependant, nous recommandons que les applications, lorsqu'elles analysent de tels en-têtes, reconnaissent un LF unique comme terminateur de ligne et ignorent le CR précédent.
Le jeu de caractères d'un corps d'entité DEVRAIT être étiqueté comme le plus petit dénominateur commun des codes de caractères utilisés dans ce corps, à l'exception près qu'il est préférable de ne pas étiqueter l'entité plutôt que de l'étiqueter avec les libellés US-ASCII ou ISO-8859-1. Voir les sections 3.7.1 et 3.4.1.
Des règles supplémentaires concernant les exigences d'analyse et d'encodage des dates, ainsi que d'autres problèmes potentiels liés à l'encodage des dates, comprennent :
- Les clients et caches HTTP/1.1 DEVRAIENT supposer qu'une date
RFC-850 qui semble se situer à plus de 50 ans dans le futur est
en réalité dans le passé (cela aide à résoudre le problème de
« l'an 2000 »).
- Une implémentation HTTP/1.1 PEUT représenter en interne une date
Expires analysée comme antérieure à la valeur correcte, mais NE
DOIT PAS la représenter en interne comme postérieure à la valeur
correcte.
- Toutes les représentations temporelles liées à l'expiration
DOIVENT être effectuées en GMT. Le fuseau horaire local NE DOIT
PAS influencer le calcul ni la comparaison d'un âge ou d'un
instant d'expiration.
- Si un en-tête HTTP transmet incorrectement une valeur de date
assortie d'un fuseau horaire autre que GMT, elle DOIT être
convertie en GMT en utilisant la conversion la plus conservatrice
possible.
19.4 Differences Between HTTP Entities and RFC 2045 Entities (Différences entre les entités HTTP et les entités RFC 2045)
HTTP/1.1 utilise de nombreuses constructions définies pour le courrier Internet (RFC 822 [9]) et les Multipurpose Internet Mail Extensions (MIME [7]) afin de permettre la transmission d'entités sous diverses représentations et selon des mécanismes extensibles. Cependant, le RFC 2045 traite du courrier électronique, et HTTP possède quelques fonctionnalités qui diffèrent de celles décrites dans le RFC 2045. Ces différences ont été choisies avec soin afin d'optimiser les performances sur les connexions binaires, de laisser une plus grande liberté dans l'utilisation de nouveaux types de médias, de faciliter les comparaisons de dates et de reconnaître les pratiques de certaines des premières implémentations de serveurs et de clients HTTP.
Cette annexe décrit des domaines spécifiques dans lesquels HTTP diffère du RFC 2045. Les proxys et passerelles vers des environnements MIME stricts DEVRAIENT être conscients de ces différences et assurer les conversions appropriées lorsque cela est nécessaire. Les proxys et passerelles depuis des environnements MIME vers HTTP doivent également être conscients de ces différences, car certaines conversions peuvent s'avérer nécessaires.
19.4.1 MIME-Version
HTTP n'est pas un protocole conforme à MIME. Cependant, les messages HTTP/1.1 PEUVENT inclure un champ d'en-tête général MIME-Version unique afin d'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 le RFC 2045[7]). Les proxys/passerelles sont responsables d'assurer la pleine conformité (lorsque cela est possible) lors de l'exportation de messages HTTP vers des environnements MIME stricts.
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
La version MIME "1.0" est la valeur par défaut pour une utilisation dans HTTP/1.1. Cependant, l'analyse et la sémantique des messages HTTP/1.1 sont définies par le présent document et non par la spécification MIME.
19.4.2 Conversion to Canonical Form (Conversion en forme canonique)
Le RFC 2045 [7] exige que les entités de courrier Internet soient converties en forme canonique avant d'être transférées, comme décrit à la section 4 du RFC 2049 [48]. La section 3.7.1 du présent document décrit les formes autorisées pour les sous-types du type de média "text" lorsqu'ils sont transmis via HTTP. Le RFC 2046 exige que le contenu de type "text" représente les sauts de ligne par CRLF et interdit l'utilisation de CR ou LF en dehors des séquences de saut de ligne. HTTP autorise l'utilisation de CRLF, d'un CR isolé et d'un LF isolé pour indiquer un saut de ligne dans un contenu textuel lorsqu'un message est transmis via HTTP.
Lorsque cela est possible, un proxy ou une passerelle de HTTP vers un environnement MIME strict DEVRAIT convertir tous les sauts de ligne des types de médias textuels décrits à la section 3.7.1 du présent document en la forme canonique CRLF du RFC 2049. Notez cependant que cela peut être compliqué par la présence d'un Content-Encoding et par le fait que HTTP autorise l'utilisation de certains jeux de caractères qui n'emploient pas les octets 13 et 10 pour représenter CR et LF, comme c'est le cas pour certains jeux de caractères multi-octets.
Les implémenteurs doivent noter que la conversion détruira toute somme de contrôle cryptographique appliquée au contenu original, à moins que ce 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.
19.4.3 Conversion of Date Formats (Conversion des formats de date)
HTTP/1.1 utilise un ensemble restreint de formats de date (section 3.3.1) afin de simplifier le processus de comparaison des dates. Les proxys et passerelles provenant 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.
19.4.4 Introduction of Content-Encoding (Introduction de Content-Encoding)
Le RFC 2045 ne comprend aucun concept équivalent au champ d'en-tête
Content-Encoding de HTTP/1.1. Puisque celui-ci agit comme un
modificateur du type de média, les proxys et passerelles de HTTP vers
des protocoles conformes à MIME DOIVENT soit modifier la valeur du
champ d'en-tête Content-Type, soit décoder le corps de l'entité avant
de transmettre le message. (Certaines applications expérimentales de
Content-Type pour le courrier Internet ont utilisé un paramètre de
type de média ";conversions=<content-coding>" pour remplir une
fonction équivalente à Content-Encoding. Cependant, ce paramètre ne
fait pas partie du RFC 2045.)
19.4.5 No Content-Transfer-Encoding (Absence de Content-Transfer-Encoding)
HTTP n'utilise pas le champ Content-Transfer-Encoding (CTE) du RFC 2045. Les proxys et passerelles allant de protocoles conformes à MIME vers HTTP DOIVENT supprimer tout encodage CTE non identity ("quoted-printable" ou "base64") avant de délivrer le message de réponse à un client HTTP.
Les proxys et passerelles allant de HTTP vers des protocoles conformes à MIME sont responsables de s'assurer que le message est dans le format correct et possède l'encodage approprié pour un transport sûr sur ce protocole, où « transport sûr » est défini par les limitations du protocole utilisé. Un tel proxy ou passerelle DEVRAIT étiqueter les données avec un Content-Transfer-Encoding approprié si cela est susceptible d'améliorer la sécurité du transport sur le protocole de destination.
19.4.6 Introduction of Transfer-Encoding (Introduction de Transfer-Encoding)
HTTP/1.1 introduit le champ d'en-tête Transfer-Encoding (section 14.41). Les proxys/passerelles DOIVENT supprimer tout transfer-coding avant de transmettre un message via un protocole conforme à MIME.
Un processus de décodage du "chunked" transfer-coding (section 3.6) peut être représenté en pseudo-code de la manière suivante :
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
19.4.7 MHTML and Line Length Limitations (MHTML et limitations de longueur de ligne)
Les implémentations HTTP qui partagent du code avec des implémentations MHTML [45] doivent tenir compte des limitations de longueur de ligne de MIME. Puisque HTTP n'a pas cette limitation, HTTP ne replie pas les lignes longues. Les messages MHTML transportés par HTTP suivent toutes les conventions de MHTML, y compris les limitations de longueur de ligne, le repliement, la canonisation, etc., car HTTP transporte tous les corps de message en tant que charge utile (voir la section 3.7.2) et n'interprète pas le contenu ni les éventuelles lignes d'en-tête MIME qu'ils pourraient contenir.
19.5 Additional Features (Fonctionnalités supplémentaires)
Les RFC 1945 et RFC 2068 documentent des éléments de protocole utilisés par certaines implémentations HTTP existantes, mais qui ne sont ni implémentés de manière cohérente ni corrects dans la majorité des applications HTTP/1.1. Les implémenteurs sont invités à prendre connaissance de ces fonctionnalités, mais ne peuvent compter ni sur leur présence dans les autres applications HTTP/1.1, ni sur leur interopérabilité. Certaines d'entre elles décrivent des fonctionnalités expérimentales proposées, et d'autres décrivent des fonctionnalités que le déploiement expérimental a jugées inadéquates et qui sont désormais traitées dans la spécification de base de HTTP/1.1.
Un certain nombre d'autres en-têtes, tels que Content-Disposition et Title, issus de SMTP et de MIME, sont également fréquemment implémentés (voir le RFC 2076 [37]).
19.5.1 Content-Disposition
Le champ d'en-tête de réponse Content-Disposition a été proposé comme moyen pour le serveur d'origine de suggérer un nom de fichier par défaut si l'utilisateur demande que le contenu soit enregistré dans un fichier. Cet usage est dérivé de la définition de Content-Disposition dans le RFC 1806 [35].
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
Voici un exemple :
Content-Disposition: attachment; filename="fname.ext"
L'agent utilisateur destinataire NE DEVRAIT PAS tenir compte des informations de chemin de répertoire présentes dans le paramètre filename-parm, qui est le seul paramètre considéré à ce jour comme applicable aux implémentations HTTP. Le nom de fichier DEVRAIT être traité uniquement comme un composant terminal.
Si cet en-tête est utilisé dans une réponse dont le content-type est application/octet-stream, la suggestion implicite est que l'agent utilisateur ne devrait pas afficher la réponse, mais accéder directement à une boîte de dialogue `save response as...'.
Voir la section 15.5 pour les questions de sécurité relatives à Content-Disposition.
19.6 Compatibility with Previous Versions (Compatibilité avec les versions antérieures)
Il dépasse le cadre d'une spécification de protocole d'imposer la conformité avec les versions antérieures. HTTP/1.1 a toutefois été délibérément conçu pour faciliter la prise en charge des versions antérieures. Il convient de noter qu'au moment de la rédaction de cette spécification (1996), on attendait des serveurs HTTP/1.1 commerciaux qu'ils :
- reconnaissent le format de la Request-Line pour les requêtes
HTTP/0.9, 1.0 et 1.1 ;
- comprennent toute requête valide au format HTTP/0.9, 1.0 ou
1.1 ;
- répondent de manière appropriée par un message de la même
version majeure que celle utilisée par le client.
Et l'on attendait des clients HTTP/1.1 qu'ils :
- reconnaissent le format de la Status-Line pour les réponses
HTTP/1.0 et 1.1 ;
- comprennent toute réponse valide au format HTTP/0.9, 1.0 ou
1.1.
Pour la plupart des implémentations de HTTP/1.0, chaque connexion est établie par le client avant la requête et fermée par le serveur après l'envoi de la réponse. Certaines implémentations mettent en œuvre la version Keep-Alive des connexions persistantes décrite à la section 19.7.1 du RFC 2068 [33].
19.6.1 Changes from HTTP/1.0 (Modifications par rapport à HTTP/1.0)
Cette section résume les principales différences entre les versions HTTP/1.0 et HTTP/1.1.
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses (Modifications visant à simplifier les serveurs Web multi-domiciliés et à préserver les adresses IP)
Les exigences selon lesquelles les clients et les serveurs doivent prendre en charge l'en-tête de requête Host, signaler une erreur si l'en-tête de requête Host (section 14.23) est absent d'une requête HTTP/1.1, et accepter les URI absolus (section 5.1.2) comptent parmi les changements les plus importants définis par cette spécification.
Les clients HTTP/1.0 plus anciens supposaient une relation biunivoque entre les adresses IP et les serveurs ; il n'existait aucun autre mécanisme établi permettant de distinguer le serveur visé par une requête, si ce n'est l'adresse IP à laquelle cette requête était adressée. Les changements exposés ci-dessus permettront à Internet, une fois que les anciens clients HTTP ne seront plus courants, de prendre en charge plusieurs sites Web à partir d'une seule adresse IP, simplifiant grandement les grands serveurs Web opérationnels, pour lesquels l'allocation de nombreuses adresses IP à un même hôte a engendré de sérieux problèmes. Internet pourra également récupérer les adresses IP qui avaient été allouées dans le seul but de permettre à des noms de domaine dédiés d'être utilisés dans des URL HTTP de niveau racine. Compte tenu du rythme de croissance du Web et du nombre de serveurs déjà déployés, il est extrêmement important que toutes les implémentations de HTTP (y compris les mises à jour des applications HTTP/1.0 existantes) implémentent correctement ces exigences :
- Les clients comme les serveurs DOIVENT prendre en charge
l'en-tête de requête Host.
- Un client qui envoie une requête HTTP/1.1 DOIT envoyer un
en-tête Host.
- Les serveurs DOIVENT signaler une erreur 400 (Bad Request) si
une requête HTTP/1.1 ne comporte pas d'en-tête de requête Host.
- Les serveurs DOIVENT accepter les URI absolus.
19.6.2 Compatibility with HTTP/1.0 Persistent Connections (Compatibilité avec les connexions persistantes HTTP/1.0)
Certains clients et serveurs peuvent souhaiter rester compatibles avec certaines implémentations antérieures des connexions persistantes dans les clients et serveurs HTTP/1.0. Les connexions persistantes en HTTP/1.0 font l'objet d'une négociation explicite, car elles ne constituent pas le comportement par défaut. Les implémentations expérimentales des connexions persistantes en HTTP/1.0 étaient défectueuses, et les nouvelles fonctionnalités de HTTP/1.1 ont été conçues pour corriger ces problèmes. Le problème venait de ce que certains clients 1.0 existants pouvaient envoyer Keep-Alive à un serveur proxy ne comprenant pas Connection, lequel le transmettait à tort au serveur entrant suivant, qui établissait alors une connexion Keep-Alive et provoquait le blocage du proxy HTTP/1.0 en attente de la fermeture de la réponse. Il en résulte que les clients HTTP/1.0 doivent être empêchés d'utiliser Keep-Alive lorsqu'ils communiquent avec des proxys.
Cependant, communiquer avec des proxys constitue l'usage le plus important des connexions persistantes, de sorte que cette interdiction est manifestement inacceptable. Un autre mécanisme est donc nécessaire pour indiquer qu'une connexion persistante est souhaitée, mécanisme dont l'usage soit sûr même lorsque l'on communique avec un ancien proxy qui ignore Connection. Les connexions persistantes constituent le comportement par défaut pour les messages HTTP/1.1 ; nous introduisons un nouveau mot-clé (Connection: close) pour déclarer la non-persistance. Voir la section 14.10.
La forme originale des connexions persistantes en HTTP/1.0 (les en-têtes Connection: Keep-Alive et Keep-Alive) est documentée dans le RFC 2068. [33]
19.6.3 Changes from RFC 2068 (Modifications par rapport au RFC 2068)
Cette spécification a fait l'objet d'un audit rigoureux visant à corriger l'emploi des mots-clés et à lever les ambiguïtés — le RFC 2068 présentait de nombreux problèmes au regard des conventions établies par le RFC 2119 [34].
Clarification du code d'erreur à utiliser en cas de défaillance d'un serveur entrant (par exemple une défaillance DNS). (Section 10.5.5)
CREATE comportait une situation de compétition qui exigeait qu'un Etag soit envoyé lors de la création initiale d'une ressource. (Section 10.2.2)
Content-Base a été retiré de la spécification : il n'était pas largement implémenté, et il n'existe pas de manière simple et sûre de l'introduire sans un mécanisme d'extension robuste. De plus, il est utilisé dans MHTML [45] d'une manière similaire mais non identique.
Le transfer-coding et la longueur des messages interagissent d'une manière qui a imposé de corriger précisément les cas dans lesquels l'encodage chunked est utilisé (afin de permettre des encodages de transfert qui pourraient n'être pas auto-délimitants). Il était important de préciser exactement la façon dont les longueurs de message sont calculées. (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
Un content-coding "identity" a été introduit afin de résoudre des problèmes découverts dans la mise en cache. (Section 3.5)
Les valeurs de qualité nulles devraient indiquer que « je ne veux pas de cela » afin de permettre aux clients de refuser une représentation. (Section 3.9)
L'utilisation et l'interprétation des numéros de version HTTP ont été clarifiées par le RFC 2145. Il est exigé des proxys qu'ils mettent à niveau les requêtes vers la version de protocole la plus élevée qu'ils prennent en charge, afin de traiter des problèmes découverts dans les implémentations HTTP/1.0. (Section 3.1)
La spécification par joker des jeux de caractères a été introduite afin d'éviter la prolifération des noms de jeux de caractères dans les en-têtes accept. (Section 14.2)
Un cas avait été omis dans le modèle Cache-Control de HTTP/1.1 : s-maxage a été introduit pour ajouter ce cas manquant. (Sections 13.4, 14.8, 14.9, 14.9.3)
La directive Cache-Control: max-age n'était pas correctement définie pour les réponses. (Section 14.9.3)
Il existe des situations dans lesquelles un serveur (en particulier un proxy) ne connaît pas la longueur totale d'une réponse, mais est capable de traiter une requête byterange. Nous avons donc besoin d'un mécanisme permettant d'autoriser les byteranges avec un content-range n'indiquant pas la longueur totale du message. (Section 14.16)
Les réponses aux requêtes Range seraient extrêmement verbeuses si toutes les métadonnées étaient systématiquement renvoyées ; en permettant au serveur de n'envoyer que les en-têtes nécessaires dans une réponse 206, ce problème peut être évité. (Sections 10.2.7, 13.5.3 et 14.27)
Correction d'un problème relatif aux requêtes de plage impossibles à satisfaire. Il existe deux cas : un problème de syntaxe, et le cas où la plage n'existe pas dans le document. Le code d'état 416 s'est révélé nécessaire pour lever cette ambiguïté, car il est requis pour signaler une erreur en cas de requête de plage d'octets située en dehors du contenu réel du document. (Sections 10.4.17, 14.16)
Réécriture des exigences relatives à la transmission des messages afin qu'il soit plus difficile pour les implémenteurs de commettre des erreurs, les conséquences d'une erreur en la matière pouvant avoir un impact significatif sur Internet, et afin de traiter les problèmes suivants :
1. Remplacement de « HTTP/1.1 or later » par « HTTP/1.1 », dans
des contextes où cela imposait par erreur des exigences quant au
comportement d'implémentations de futures versions de
HTTP/1.x.
2. Clarification du fait que les agents utilisateurs, et non les
« clients » en général, réessaient les requêtes.
3. Conversion des exigences relatives au fait que les clients
ignorent les réponses 100 (Continue) inattendues, et que les
proxys retransmettent les réponses 100, en une exigence générale
portant sur les réponses 1xx.
4. Correction de certaines formulations spécifiques à TCP, afin
d'indiquer plus clairement que des transports non TCP sont
possibles pour HTTP.
5. Exigence selon laquelle un serveur d'origine NE DOIT PAS
attendre le corps de la requête avant d'envoyer une réponse 100
(Continue) requise.
6. Autorisation, plutôt qu'exigence, pour un serveur d'omettre
100 (Continue) s'il a déjà reçu une partie du corps de la
requête.
7. Possibilité pour les serveurs de se prémunir contre les
attaques par déni de service et contre les clients défectueux.
Ce changement ajoute l'en-tête Expect et le code d'état 417. Les modifications relatives aux exigences de transmission des messages figurent aux sections 8.2, 10.4.18, 8.1.2.2, 13.11 et 14.20.
Les proxys devraient pouvoir ajouter Content-Length lorsque cela est approprié. (Section 13.5.2)
Clarification de la confusion entre les réponses 403 et 404. (Sections 10.4.4, 10.4.5 et 10.4.11)
Les avertissements pouvaient être mis en cache de manière incorrecte, ou ne pas être mis à jour correctement. (Sections 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3 et 14.46) Warning devait également être un en-tête général, car PUT et d'autres méthodes peuvent nécessiter des avertissements dans les requêtes.
Les transfer-codings présentaient des problèmes majeurs, en particulier dans leurs interactions avec l'encodage chunked. La solution consiste à conférer aux transfer-codings le même statut de plein droit qu'aux content-codings. Cela implique l'ajout d'un registre IANA pour les transfer-codings (distinct des content codings), d'un nouvel en-tête (TE) et l'activation de futurs en-têtes de fin (trailers). Les encodages de transfert constituent un gain de performance majeur, de sorte qu'il valait la peine de les corriger [39]. TE résout également un autre problème obscur de compatibilité ascendante qui aurait pu survenir de l'interaction entre les trailers d'authentification, l'encodage chunked et les clients HTTP/1.0. (Sections 3.6, 3.6.1 et 14.39)
Les méthodes PATCH, LINK et UNLINK étaient définies dans une version antérieure de cette spécification, mais n'étaient pas couramment implémentées. Voir le RFC 2068 [33].
Les champs d'en-tête Alternates, Content-Version, Derived-From, Link, URI, Public et Content-Base étaient définis dans une version antérieure de cette spécification, mais n'étaient pas couramment implémentés. Voir le RFC 2068 [33].
20 Index (Index)
Veuillez consulter la version PostScript de ce RFC pour l'INDEX.
- Full Copyright Statement (Déclaration de droits d'auteur intégrale)
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.