MDN’s new design is in Beta! A sneak peek: https://blog.mozilla.org/opendesign/mdns-new-design-beta/

L'évolution du language HTTP

Cette traduction est incomplète. Aidez à traduire cet article depuis l'anglais.

Le language HTTP est le protocole sous-jacent du World Wide Web. Il a connu de nombreuses modifications depuis son invention par Tim Berners-Lee dans les années 1989-1991, en gardant dans l'ensemble une simplicité et en faconnant une plus grande flexibilité. Il a évolué du protocole initial, qui permettait d'échanger des fichiers dans un environnement de laboratoire plus ou moins fiable, au labyrinthe moderne qu'est Internet, et transporte désormais des images et vidéos en grande résolution et en 3D.

L'invention du World Wide Web

 

En 1989, alors qu'il travaillait au CERN, Tim Berners-Lee proposa la création d'un système hypertexte sur internet. Initialement nommé Mesh, il prit alors le nom de World Wide Web lors de sa mise en place en 1990. Bâti sur les protocoles existants TCP et IP, il consistait de quatre éléments de base:

  • Un format textuel pour représenter les documents hypertextes, le HyperText Markup Language (HTML).
  • Un protocole simple pour échanger ces documents, le HypertText Transfer Protocol (HTTP).
  • Un client pour exposer (et accidentellement modifier) ces documents, le premier moteur de recherche nommé WorldWideWeb.
  • Un serveur pour garantir l'accès au document, une version précoce du httpd.

Ces quatres composantes étaient réalisés dès fin 1990, et les premiers serveurs tournaient déjà en dehors du CERN au debut 1991. Le 6 Août 1991, la publication de Tim Berners-Lee sur le groupe de discussion public alt.hypertext est dès lors considérée comme le point de départ officiel du World Wide Web en tant que projet publique.

Le protocole HTTP utilisé dans ces premières phases était très simple. Plus tard surnommé HTTP/0.9, il était aussi parfois surnommé le protocole d'une ligne.

HTTP/0.9 – Le protocole d'une ligne

La version initiale de HTTP n'avait pas de numéro de version et fut appelé 0.9 pour la différencier des versions ultérieures. HTTP/0.9 est extrêmement simple: la requête se compose d'une seule ligne et commence par la seule méthode possible GET, suivi par le chemin pour accéder à la ressource (pas l'URL puisque le protocole, le serveur et le port ne sont pas nécessaires lorsqu'on est connecté au serveur).

GET /mypage.html

La réponse est extrêmement simple elle aussi: elle consiste simplement du fichier en lui-même.

<HTML>
A very simple HTML page
</HTML>

Contrairement aux évolutions suivantes, il n'y avait pas d'en-tête HTTP, ce qui signifie que seulement des fichiers HTML pouvaient être transmis et aucun autre type de documents. Il n'existait pas de code d'erreur ou d'état: en cas de problème, un fichier HTML particulier était renvoyé au consommateur avec une description du problème qu'il comprenait.

HTTP/1.0 – Construire l'extensibilité

HTTP/0.9 était très limité, et les navigateurs et serveurs l'ont rapidement étiré vers un usage plus polyvalent.

  • Dans chaque requête figure désormais les informations de version (HTTP/1.0 est annexé à la ligne GET).
  • Une ligne de code d'état est aussi envoyée au debut de chaque réponse, et permet au navigateur de comprendre le succès ou échec de la requête, et donc de s'adapter en conséquence (par une mise à jour par exemple ou en utilisant son cache local de manière spécifique).
  • La notion d'en-tête HTTP a été mise en place, à la fois pour les requêtes et pour les réponses, et permet la transmission de métadata et rendant le protocole extrêmement flexible et extensible.
  • Avec les nouvelles en-têtes HTTP, il est possible de transmettre des documents autre que des fichiers HTML bruts, grâce à l'en-tête Content-Type.

Une requête typique ressemblait donc a ceci :

GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML> 
A page with an image
  <IMG SRC="/myimage.gif">
</HTML>

Suivi d'une seconde connexion et requête pour extraire l'image :

GET /myimage.gif HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/gif
(image content)

Ces innovations n'ont pas été mises en place par un effort concerté, mais par une approche expérimentale pendant les années 1991-1995: un serveur et un navigateur ajoutaient une caractéristique et attendaient de voir si elle suscitait l'attrait souhaité. Beaucoup de problèmes d'interoperabilité étaient communs. Pour régler ces désagréments, un document d'information décrivant les pratiques communes à été publié en Novembre 1996, RFC 1945. Ceci est la définition de HTTP/1.0 et il convient de noter que, dans le sens strict du terme, ce n'est pas la norme officielle.

HTTP/1.1 – Le protocole standardisé

 

En parrallèle aux utilisations quelque peu chaotiques des différentes applications de HTTP/1.0, et depuis 1995, bien avant la publication des documents HTTP/1.0 l'année suivante, une standardisation adéquate était en cours. HTTP/1.1 était la première version standardisée et fut publiée début 1997, quelques mois seulements après HTTP/1.0.

HTTP/1.1 clarifiait des ambiguïtés et instaurait de nombreuses améliorations.

  • Une connexion peut être réutilisée, économisant le temps qu'il faudrait pour la ré-ouvrir de nombreuses fois pour présenter les resources intégrés dans le document original extrait.
  • L'ajout du pipelining, qui permet d'envoyer une seconde requête avant que la réponse de la première soit complètement transmise, diminuant le temps de latence des communications.
  • Désormais les réponses en morceaux sont aussi supportées.
  • Mise en place de mécanismes de contrôle de caches additionnels.
  • La negociation du contenu, dont le language, de l'encodement, ou le type, a été mis en place et permet au client et au serveur de se mettre d'accord sur le contenu le plus adéquat à échanger.
  • Grâce à l'en-tête Host, la capacité d'héberger différents domaines avec la même adresse IP permet désormais une collocation de serveurs.

Une suite typique de requêtes, toutes à travers la même connexion, ressemble désormais à ceci:

GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding

(content)


GET /static/img/header-background.png HTTP/1.1
Host: developer.cdn.mozilla.net
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header

200 OK
Age: 9578461
Cache-Control: public, max-age=315360000
Connection: keep-alive
Content-Length: 3077
Content-Type: image/png
Date: Thu, 31 Mar 2016 13:34:46 GMT
Last-Modified: Wed, 21 Oct 2015 18:27:50 GMT
Server: Apache

(image content of 3077 bytes)

HTTP/1.1 a été publié pour la première fois en tant que RFC 2068 en Janvier 2017.

Plus de quinzes années d'extensions

Grâce à son extensibilité (il est facile de créer de nouveaux en-têtes et méthodes) et bien que le protocole HTTP/1.1 a été améloiré à travers deux révisions, RFC 2616 publié en Juin 1999, et les séries RFC 7230-RFC 7235 publiées en Juin 2014 en prévision de la publication de HTTP/2, ce protocole s'est montré extrêmement stable pendant plus de quinze ans.

HTTP pour des transmissions sécurisés

La modification principale du protocole HTTP a été faite vers la fin de l'année 1994. Au lieu d'envoyer HTTP vers une pile TCP/IP basique, Netscape Communication avait ajouté une couche additionnelle de transission encryptée: SSL. SSL 1.0 n'est jamais paru en dehors des entreprises, mais SSL 2.0 et ses successeurs SSL 3.0 et SSL 3.1 ont permi, grâce à l'encryption, aux sites Web du e-commerce de garantir l'authenticité des messages echangés entre le serveur et le client. Le SSL a été placé dans les standards internationaux et est éventuellement devenu TLS, avec les versions 1.0, 1.1 et 1.2 aparaissant successivement pour clore les vulnérabilités. TLS 1.3 est actuellement en progrès.

Dans le même temps, le besoin d'une couche de transport cryptée était de plus en plus important: le web avait perdu la fiabilité relative d'un réseau principallement académique pour devenir une jungle où publicitaires, individus aléatoires ou criminels rivalisent pour obtenir le maximum de données privées sur les utilisateurs, tentent d'usurper leur identité ou bien même de remplacer les données transmises par ceux altérés. Alors que les applications crées avec HTTP devenaient de plus en plus puissantes, ayant accès à de plus en plus de données privées tels que des listes de contacts, e-mail, ou la position géographique de l'utilisateur, le besoin d'un TLS devenait omniprésent, bien même en dehors du cas du e-commerce.

Using HTTP for complex applications

The original vision of Tim Berners-Lee for the Web wasn't a read-only medium. He envisioned a Web where people can add and move documents remotely, a kind of distributed file system. Around 1996, HTTP has been extended to allow authoring, and a standard called WebDAV was created. It has been further extended for specific applications like CardDAV to handle address book entries and CalDAV to deal with calendars. But all these *DAV extensions had a flaw: they had to be implemented by the servers to be used, which was quite complex. Their use on Web realms stayed confidential.

In 2000, a new pattern for using HTTP was designed: representational state transfer (or REST). The actions induced by the API were no more conveyed by new HTTP methods, but only by accessing specific URIs with basic HTTP/1.1 methods. This allowed any Web application to provide an API to allow retrieval and modification of its data without having to update the browsers or the servers: all what is needed was embedded in the files served by the Web sites through standard HTTP/1.1. The drawback of the REST model resides in the fact that each website defines its own non-standard RESTful API and has total control on it; unlike the *DAV extensions were clients and servers are interoperable. RESTful APIs became very common in the 2010s.

Since 2005, the set of APIs available to Web pages greatly increased and several of these APIs created extensions, mostly new specific HTTP headers, to the HTTP protocol for specific purposes:

  • Server-sent events, where the server can push occasional messages to the browser.
  • WebSocket, a new protocol that can be set up by upgrading an existing HTTP connection.

Relaxing the security-model of the Web

HTTP is independent of the security model of the Web, the same-origin policy. In fact, the current Web security model has been developed after the creation of HTTP! Over the years, it has proved useful to be able to be more lenient, by allowing under certain constraints to lift some of the restriction of this policy. How much and when such restrictions are lifted is transmitted by the server to the client using a new bunch of HTTP headers. These are defined in specifications like Cross-Origin Resource Sharing (CORS) or the Content Security Policy (CSP).

In addition to these large extensions, numerous other headers have been added, sometimes experimentally only. Notable headers are Do Not Track (DNT) header to control privacy, X-Frame-Options, or Upgrade-Insecure-Requests but many more exist.

HTTP/2 – A protocol for greater performance

Over the years, Web pages have become much more complex, even becoming applications in their own right. The amount of visual media displayed, the volume and size of  scripts adding interactivity, has also increased: much more data is transmitted over significantly more HTTP requests. HTTP/1.1 connections need requests sent in the correct order. Theoretically, several parallel connections could be used (typically between 5 and 8), bringing considerable overhead and complexity. For example, HTTP pipelining has emerged as a resource burden in Web development.

In the first half of the 2010s, Google demonstrated an alternative way of exchanging data between client and server, by implementing an experimental protocol SPDY. This amassed interest from developers working on both browsers and servers. Defining an increase in responsiveness, and solving the problem of duplication of data transmitted, SPDY served as the foundations of the HTTP/2 protocol.

The HTTP/2 protocol has several prime differences from the HTTP/1.1 version:

  • It is a binary protocol rather than text. It can no longer be read and created manually despite this hurdle, improved optimization techniques can now be implemented.
  • It is a multiplexed protocol. Parallel requests can be handled over the same connection, removing the order and blocking constraints of the HTTP/1.x protocol.
  • It compresses headers. As these are often similar among a set of requests, this removes duplication and overhead of data transmitted.
  • It allows a server to populate data in a client cache, in advance of it being required, through a mechanism called the server push.

Officially standardized, in May 2015, HTTP/2 has had much success. By July 2016, 8.7% of all Web sites[1] were already using it, representing more than 68% of all requests[2]. High-traffic Web sites showed the most rapid adoption, saving considerably on data transfer overheads and subsequent budgets.

This rapid adoption rate was likely as HTTP/2 does not require adaptation of Web sites and applications: using HTTP/1.1 or HTTP/2 is transparent for them. Having an up-to-date server communicating with a recent browser is enough to enable its use: only a limited set of groups were needed to trigger adoption, and as legacy browser and server versions are renewed, usage has naturally increased, without further Web developer efforts.

Post-HTTP/2 evolution

HTTP didn't stop evolving upon the release of HTTP/2. Like with HTTP/1.x previously, HTTP's extensibility is still beinig used to add new features. Notably, we can cite new extensions of the HTTP protocol appearing in 2016:

  • Support of Alt-Svc allows the dissociation of the identification and the location of a given resource, allowing for a smarter CDN caching mechanism.
  • The introduction of Client-Hints allows the browser, or client, to proactively communicate information about its requirements, or hardware constraints, to the server.
  • The introduction of security-related prefixes in the Cookie header, now helps guarantee a secure cookie has not been altered.

This evolution of HTTP proves its extensibility and simplicity, liberating creation of many applications and compelling the adoption of the protocol. The environment in which HTTP is used today is quite different from that seen in the early 1990s. HTTP's original design proved to be a masterpiece, allowing the Web to evolve over a quarter of a century, without the need of a mutiny. By healing flaws, yet retaining the flexibility and extensibility which made HTTP such a success, the adoption of HTTP/2 hints at a bright future for the protocol.

Étiquettes et contributeurs liés au document

 Contributeurs à cette page : Tiplouf
 Dernière mise à jour par : Tiplouf,