Annexe A. Historique des versions HTTP
HTTP est utilisé depuis 1990. La première version, appelée plus tard HTTP/0.9, était un protocole simple de transfert de données hypertexte sur l'Internet, n'utilisant qu'une seule méthode de requête (GET) et aucune métadonnée. HTTP/1.0, tel que défini par [RFC1945], a ajouté un ensemble de méthodes de requête et une messagerie de type MIME, permettant de transférer des métadonnées et de placer des modificateurs sur la sémantique requête/réponse. Cependant, HTTP/1.0 ne tenait pas suffisamment compte des effets des proxies hiérarchiques, de la mise en cache, du besoin de connexions persistantes, ni des hôtes virtuels fondés sur le nom. La prolifération d'applications incomplètement implémentées se réclamant de « HTTP/1.0 » a rendu d'autant plus nécessaire un changement de version du protocole, afin que deux applications communicantes puissent déterminer leurs capacités réelles respectives.
HTTP/1.1 reste compatible avec HTTP/1.0 en incluant des exigences plus strictes qui permettent des implémentations fiables, en n'ajoutant que les fonctionnalités qui peuvent soit être ignorées sans danger par un destinataire HTTP/1.0, soit n'être envoyées que lors d'une communication avec une partie annonçant sa conformité à HTTP/1.1.
HTTP/1.1 a été conçu pour faciliter la prise en charge des versions précédentes. Un serveur HTTP/1.1 généraliste devrait être capable de comprendre toute requête valide au format HTTP/1.0, en répondant de manière appropriée par un message HTTP/1.1 qui n'utilise que des fonctionnalités comprises (ou ignorées sans danger) par les clients HTTP/1.0. De même, on peut s'attendre à ce qu'un client HTTP/1.1 comprenne toute réponse HTTP/1.0 valide.
Comme HTTP/0.9 ne prenait pas en charge les champs d'en-tête dans une requête, il n'existe aucun mécanisme lui permettant de prendre en charge les hôtes virtuels fondés sur le nom (sélection de la ressource par examen du champ d'en-tête Host). Tout serveur qui implémente des hôtes virtuels fondés sur le nom devrait désactiver la prise en charge de HTTP/0.9. La plupart des requêtes qui semblent être du HTTP/0.9 sont en fait des requêtes HTTP/1.x mal construites, dues à un client qui échoue à encoder correctement la cible de requête.
A.1. Changements par rapport à HTTP/1.0
Cette section résume les différences majeures entre les versions HTTP/1.0 et HTTP/1.1.
A.1.1. Serveurs Web multirésidents
Les exigences selon lesquelles les clients et les serveurs prennent en charge le champ d'en-tête Host (Section 5.4), signalent une erreur s'il est absent d'une requête HTTP/1.1, et acceptent les URI absolus (Section 5.3) comptent parmi les changements les plus importants définis par HTTP/1.1.
Les clients HTTP/1.0 plus anciens supposaient une relation biunivoque entre adresses IP et serveurs ; il n'existait aucun autre mécanisme établi pour distinguer le serveur visé par une requête que l'adresse IP vers laquelle cette requête était dirigée. Le champ d'en-tête Host a été introduit pendant le développement de HTTP/1.1 et, bien qu'il ait été rapidement implémenté par la plupart des navigateurs HTTP/1.0, des exigences supplémentaires ont été imposées à toutes les requêtes HTTP/1.1 afin de garantir une adoption complète. Au moment de la rédaction, la plupart des services fondés sur HTTP dépendent du champ d'en-tête Host pour cibler les requêtes.
A.1.2. Connexions Keep-Alive
Dans 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. Cependant, certaines implémentations mettent en œuvre la version explicitement négociée (« Keep-Alive ») des connexions persistantes décrite à la Section 19.7.1 de [RFC2068].
Certains clients et serveurs peuvent souhaiter être compatibles avec ces approches antérieures des connexions persistantes, en les négociant explicitement au moyen d'un champ d'en-tête de requête « Connection: keep-alive ». Cependant, certaines implémentations expérimentales des connexions persistantes HTTP/1.0 sont défectueuses ; par exemple, si un serveur proxy HTTP/1.0 ne comprend pas Connection, il transférera à tort ce champ d'en-tête au prochain serveur entrant, ce qui entraînerait une connexion bloquée.
Une solution tentée a été l'introduction d'un champ d'en-tête Proxy-Connection, ciblant spécifiquement les proxies. En pratique, cela s'est également révélé impraticable, car les proxies sont souvent déployés en plusieurs couches, ce qui reproduit le même problème que celui examiné ci-dessus.
En conséquence, les clients sont encouragés à ne pas envoyer le champ d'en-tête Proxy-Connection dans les requêtes.
Les clients sont également encouragés à envisager avec prudence l'usage de Connection: keep-alive dans les requêtes ; s'il peut permettre des connexions persistantes avec des serveurs HTTP/1.0, un client qui l'utilise devra surveiller la connexion à la recherche de requêtes « bloquées » (ce qui indique que le client devrait cesser d'envoyer le champ d'en-tête), et ce mécanisme ne devrait pas du tout être utilisé par les clients lorsqu'un proxy est employé.
A.1.3. Introduction de Transfer-Encoding
HTTP/1.1 introduit le champ d'en-tête Transfer-Encoding (Section 3.3.1). Les codages de transfert doivent être décodés avant de transférer un message HTTP sur un protocole conforme à MIME.
A.2. Changements par rapport à la RFC 2616
L'approche de HTTP en matière de gestion des erreurs a été expliquée. (Section 2.5)
La production ABNF HTTP-version a été clarifiée comme étant sensible à la casse. En outre, les numéros de version ont été restreints à un seul chiffre, du fait que des implémentations sont connues pour traiter incorrectement les numéros de version à plusieurs chiffres. (Section 2.6)
Le userinfo (c'est-à-dire le nom d'utilisateur et le mot de passe) n'est désormais plus autorisé dans les URI HTTP et HTTPS, en raison de problèmes de sécurité liés à sa transmission sur le réseau. (Section 2.7.1)
Le schéma d'URI HTTPS est désormais défini par cette spécification ; auparavant, il l'était à la Section 2.4 de [RFC2818]. En outre, il implique une sécurité de bout en bout. (Section 2.7.2)
Les messages HTTP peuvent être (et sont souvent) mis en mémoire tampon par les implémentations ; bien qu'il soit parfois disponible sous forme de flux, HTTP est fondamentalement un protocole orienté messages. Des tailles minimales prises en charge pour divers éléments de protocole ont été suggérées, afin d'améliorer l'interopérabilité. (Section 3)
Les espaces blancs invalides autour des noms de champs doivent désormais être rejetés, car les accepter constitue une vulnérabilité de sécurité. Les productions ABNF définissant les champs d'en-tête n'énumèrent désormais que la valeur de champ. (Section 3.2)
Les règles relatives aux espaces blancs linéaires implicites entre certaines productions grammaticales ont été supprimées ; désormais, les espaces blancs ne sont autorisés que là où ils sont spécifiquement définis dans l'ABNF. (Section 3.2.3)
Les champs d'en-tête qui s'étendent sur plusieurs lignes (« repliement de lignes ») sont obsolètes. (Section 3.2.4)
L'octet NUL n'est plus autorisé dans le texte des comment et des quoted-string, et le traitement de l'échappement par barre oblique inverse y a été clarifié. La règle quoted-pair n'autorise plus l'échappement de caractères de contrôle autres que HTAB. Le contenu non US-ASCII dans les champs d'en-tête et dans la phrase de raison a été rendu obsolète et rendu opaque (la règle TEXT a été supprimée). (Section 3.2.6)
Les champs d'en-tête Content-Length fantaisistes doivent désormais être traités comme des erreurs par les destinataires. (Section 3.3.2)
L'algorithme de détermination de la longueur du corps du message a été clarifié afin d'indiquer tous les cas particuliers (par exemple, déterminés par les méthodes ou les codes d'état) qui l'affectent, et afin d'indiquer que les nouveaux éléments de protocole ne peuvent pas définir de tels cas particuliers. CONNECT est un nouveau cas particulier dans la détermination de la longueur du corps du message. « multipart/byteranges » n'est plus un moyen de détecter la longueur du corps du message. (Section 3.3.3)
Le jeton de codage de transfert « identity » a été supprimé. (Sections 3.3 et 4)
La longueur d'un chunk ne comprend pas le décompte des octets de l'en-tête et du trailer du chunk. Le repliement de lignes dans les extensions de chunk est interdit. (Section 4.1)
La signification du codage de contenu « deflate » a été clarifiée. (Section 4.2.2)
Les composants segment + query de la RFC 3986 ont été utilisés pour définir la cible de requête, au lieu de abs_path de la RFC 1808. La forme asterisk-form de la cible de requête n'est autorisée qu'avec la méthode OPTIONS. (Section 5.3)
Le terme « Effective Request URI » a été introduit. (Section 5.5)
Les passerelles n'ont plus besoin de générer de champs d'en-tête Via. (Section 5.7.1)
Le moment exact où les options de connexion « close » doivent être envoyées a été clarifié. De plus, les champs d'en-tête « saut par saut » doivent désormais figurer dans le champ d'en-tête Connection ; le fait qu'ils soient définis comme saut par saut dans cette spécification ne les en exempte pas. (Section 6.1)
La limite de deux connexions par serveur a été supprimée. Une séquence idempotente de requêtes n'a plus à être réessayée. L'exigence de réessayer les requêtes dans certaines circonstances lorsque le serveur ferme prématurément la connexion a été supprimée. De plus, certaines exigences superflues concernant les cas où les serveurs sont autorisés à fermer prématurément des connexions ont été supprimées. (Section 6.3)
La sémantique du champ d'en-tête Upgrade est désormais définie dans les réponses autres que 101 (cela a été repris de [RFC2817]). En outre, l'ordre dans la valeur du champ est désormais significatif. (Section 6.7)
Les éléments de liste vides dans les productions de liste (par exemple un champ d'en-tête de liste contenant « , , ») sont obsolètes. (Section 7)
L'enregistrement des codages de transfert nécessite désormais un IETF Review (Section 8.4)
Cette spécification définit désormais le registre des jetons Upgrade, précédemment défini à la Section 7.2 de [RFC2817]. (Section 8.6)
L'attente de prise en charge des requêtes HTTP/0.9 a été supprimée. (Appendix A)
Les problèmes posés par les champs d'en-tête Keep-Alive et Proxy-Connection dans les requêtes sont signalés, l'usage de ce dernier étant totalement découragé. (Appendix A.1.2)