Réorganisation des normes techniques HTTP

HTTP, ça sert à quoi ?

HTTP est un protocole. Un protocole, c’est un ensemble de règles que les logiciels doivent suivre rigoureusement pour assurer l’interopérabilité, c’est-à-dire pour qu’ils puissent communiquer, même s’ils ont été développés par des organisations différentes. Le succès de l’Internet repose sur cette notion d’interopérabilité, qui garantit notamment l’indépendance par rapport à telle ou telle organisation. Ces règles qui forment le protocole sont en général écrites dans un document spécialisé, une spécification. Idéalement², cette spécification va être rédigée et publiée par une organisation de normalisation ouverte, c’est-à-dire qui assure aussi bien la publication et la diffusion libre et gratuite des textes normatifs, mais également l’ouverture à tous du processus de normalisation. Dans le cas de HTTP, cette organisation de normalisation est l’IETF (Internet Engineering Task Force) et les normes qu’elle publie se nomment les RFC³. Chaque RFC est identifié par un numéro.

Ces normes techniques disent par exemple que HTTP est un protocole client-serveur, où le serveur attend les requêtes et où le client se connecte au serveur, envoie une requête et lit une réponse. La norme précise le format exact de cette requête et de cette réponse, pour que tout client puisse parler avec tout serveur. C’est par exemple cette norme qui fixe le fait que la réponse commence par un code à trois chiffres, permettant à un logiciel client de déterminer sans ambiguïté si la requête a été bien traitée. (Vous connaissez au moins un de ces codes, le 404, qui indique au client que le serveur n’a pas pu exécuter la requête, car elle portait sur du contenu inexistant.)

Histoire et versions

HTTP a une longue histoire et a souvent changé. La toute première version de HTTP, celle développée par Tim Berners-Lee, ne faisait pas l’objet d’une normalisation formelle et était ultra-simple, quand on la compare au HTTP d’aujourd’hui. Cette version, vers 1989-1990, a reçu ensuite le numéro de version 0 mais, à l’époque, c’était la seule existante et très peu de gens avaient prévu le succès fou que serait HTTP.

La première version spécifiée formellement a été la version 1 ou, plus exactement, 1.0, en 1996⁴. Sa norme était le RFC 1945 qui n’avait pas le statut de norme à l’IETF et était conçu comme une simple description de l’existant. Cette nouvelle version introduisait de très nombreuses nouveautés et le protocole n’avait déjà plus qu’un lointain rapport avec l’original. Il avait désormais plusieurs méthodes (types de requêtes, permettant de récupérer une ressource distante mais aussi de la modifier), un mécanisme pour adjoindre des métadonnées à la requête et à la réponse, etc.

En parallèle, le travail était fait sur la future version 1.1, qui a été normalisée en 1997, dans le RFC 2068. Cette version est toujours très largement utilisée aujourd’hui. Ainsi, le collecteur du moteur de recherche de Google n’utilise que cette version.

Depuis, non seulement la norme sur la version 1.1 a été mise à jour plusieurs fois, mais deux autres versions de HTTP ont été mises au point. La version 2 a été normalisée en 2015, dans le RFC 7540. Les deux nouveautés importantes était la possibilité de récupérer des ressources en parallèle (par exemple les images d’une page Web et sa feuille de style) et le passage d’une représentation textuelle de la requête et de la réponse à une représentation binaire, plus difficile pour les humains mais plus pratique et plus efficace pour les programmes. Quant à la version 3, elle vient tout juste, en 2022, d’être normalisée, avec le RFC 9114. Le grand changement est l’abandon du protocole de transport TCP (Transmission Control Protocol), pour QUIC, qui permet un parallélisme accru et une latence plus faible.

De même que la version 2 n’a pas éliminé la version 1 (loin de là), la version 3 ne vise pas à remplacer complètement la version 2. Non seulement il est difficile de remplacer une version largement déployée et utilisée⁵, sur laquelle beaucoup d’acteurs de l’Internet comptent mais en outre chaque version a des avantages spécifiques qui sont utiles dans certains cas. Personne n’envisage donc une disparition à court terme de HTTP/1 ou HTTP/2.

Les nouvelles normes

Les anciennes normes techniques de HTTP devaient donc s’adapter à cette cohabitation sur une longue durée des trois versions. Le choix a été de séparer la normalisation des caractéristiques fondamentales de HTTP, indépendantes de la version, et la normalisation de chaque version, avec ses spécificités. Les nouvelles normes sont donc composées de :

• Le RFC 9110, qui décrit la sémantique et les concepts généraux de HTTP. Le protocole a bien grossi depuis ses débuts et ce RFC ne fait pas moins de 250 pages.
• Le RFC 9112 normalise HTTP/1 (remplaçant l’ancien RFC 7230).
• Le RFC 9113 normalise HTTP/2 (remplaçant l’ancien RFC 7540)
• Le RFC 9114 normalise HTTP/3 (première normalisation de cette version).

D’autres RFC complètent cet ensemble, comme le RFC 9111, sur la mémorisation des résultats (un moyen important d’amélioration des performances de HTTP) ou comme le RFC 9204 sur un mécanisme de compression des métadonnées, utilisé par HTTP/3.

Il s’agit juste d’une réorganisation des documents. HTTP ne change pas, à part sur des points de détail, ou bien pour corriger des erreurs. Ainsi, les logiciels qui parlaient le HTTP/1 ou le HTTP/2 n’auront typiquement pas besoin de modifications.

HTTP est fréquemment décrit comme un protocole très simple, ce qui fait qu’il est souvent utilisé dans l’enseignement, à la fois pour cette simplicité et parce qu’il permet de faire travailler les étudiants avec des exemples réels⁶. La taille de certains RFC peut être trompeuse car ils sont souvent composés de longues listes d’éléments à gérer, sans que cela augmente réellement la complexité du protocole. Toutefois, écrire un client ou un serveur HTTP complet n’est pas une mince affaire et nécessite de lire attentivement au moins le RFC 9110 et un des RFC spécifiques d’une version.

Notez que la coexistence, qui durera probablement longtemps, entre les trois versions, pose un problème pour le client HTTP. Comment peut-il savoir quelle(s) version(s) sont acceptées par le serveur ? La solution la plus sûre est de se connecter en HTTP/1 et le serveur précisera alors (par exemple via le champ Alt-Svc: de l’en-tête) quelles autres versions il gère. Mais des méthodes plus efficaces existent aussi comme le futur enregistrement SVCB/HTTPS dans le DNS.

Conclusion

En tout cas, les personnes, programmeurs, étudiants, ou simples curieux, qui voudront apprendre sérieusement HTTP auront désormais une tâche plus simple, du fait de cette meilleure organisation des normes. L’Internet évolue sans cesse et les textes normatifs ne sont pas toujours mis à jour. Félicitons donc les nombreuses personnes qui ont travaillé à nettoyer et à ranger le tas de documents.

^{1 – Ou parfois sa variante utilisant la cryptographie, HTTPS pour HTTP Secure.}