AccueilđŸ‡«đŸ‡·Chercher

Hypertext Transfer Protocol

L’HyperText Transfer Protocol, gĂ©nĂ©ralement abrĂ©gĂ© HTTP, littĂ©ralement « protocole de transfert hypertexte », est un protocole de communication client-serveur dĂ©veloppĂ© pour le World Wide Web. HTTPS (avec S pour secure, soit « sĂ©curisĂ© ») est la variante sĂ©curisĂ©e par le chiffrement et l'authentification.

Hypertext Transfer Protocol
Logiciel
Informations
Fonction Transmission d'hypertexte
Sigle HTTP
Date de création 1990
Auteur(s) / Autrice(s) Tim Berners-Lee
Port 80
RFC 1996 : RFC 1945
1997 : RFC 2068
1999 : RFC 2616
2014 : RFC 7230 Ă  7237
2015 : RFC 7540

HTTP est un protocole de la couche application dans le modÚle OSI. Il peut fonctionner sur n'importe quelle connexion fiable. Dans les faits on utilise le protocole TCP comme couche de transport. Un serveur HTTP utilise alors par défaut le port 80 (443 pour HTTPS).

Les clients HTTP les plus connus sont les navigateurs Web. Il est aussi utilisĂ© dans des interfaces de programmation d’application (API) pour accĂ©der aux donnĂ©es d'un serveur ainsi que des systĂšmes pour rĂ©cupĂ©rer automatiquement le contenu d'un site tels que les aspirateurs de site Web et les robots d'indexation.

Historique

HTTP a Ă©tĂ© inventĂ© par Tim Berners-Lee avec les adresses Web et le langage HTML pour crĂ©er le World Wide Web. À cette Ă©poque, le File Transfer Protocol (FTP) Ă©tait dĂ©jĂ  disponible pour transfĂ©rer des fichiers, mais il ne supportait pas la notion de format de donnĂ©es telle qu'introduite par Multipurpose Internet Mail Extensions (MIME). La premiĂšre version de HTTP Ă©tait trĂšs Ă©lĂ©mentaire, mais prĂ©voyait dĂ©jĂ  le support d'en-tĂȘtes MIME pour dĂ©crire les donnĂ©es transmises. Cette premiĂšre version reste encore partiellement utilisable de nos jours, connue sous le nom de HTTP/0.9.

En , la RFC 1945[1] décrit HTTP tel que communément implémenté à l'époque et connu sous le nom de HTTP/1.0. Cette version supporte la gestion de cache et l'identification.

En , HTTP/1.1 devient finalement standard de l'IETF. Il est dĂ©crit dans la RFC 2068[2] de l'IETF, puis dans la RFC 2616[3] en . Cette version ajoute le support du transfert en pipeline (ou pipelinage) et la nĂ©gociation de type de contenu (format de donnĂ©es, langue). HTTP/1.1 rend la prĂ©sence de l'entĂȘte Host obligatoire dans les requĂȘtes afin de supporter l'hĂ©bergement mutualisĂ©.

En , les travaux à propos de HTTP/2.0 démarrent à l'IETF adoptant SPDY comme matériel de départ.

En , la spécification de HTTP 1.1 a été republiée. Elle a été éclatée en plusieurs RFC et corrigée pour toutes ses imprécisions, RFC 7230[4] à RFC 7237[5].

Implémentation

MĂ©thodes

Capture d'Ă©cran d'une requĂȘte GET et de sa rĂ©ponse.

Dans le protocole HTTP, une mĂ©thode est une commande spĂ©cifiant un type de requĂȘte, c'est-Ă -dire qu'elle demande au serveur d'effectuer une action. En gĂ©nĂ©ral l'action concerne une ressource identifiĂ©e par l'URL qui suit le nom de la mĂ©thode.

Dans l'illustration ci-contre, une requĂȘte GET est envoyĂ©e pour rĂ©cupĂ©rer la page d'accueil du site web www.perdu.com :

GET / HTTP/1.1
Host: www.perdu.com

Il existe de nombreuses méthodes, les plus courantes étant GET, HEAD et POST :

GET
C'est la mĂ©thode la plus courante pour demander une ressource. Une requĂȘte GET est sans effet sur la ressource, il doit ĂȘtre possible de rĂ©pĂ©ter la requĂȘte sans effet.
HEAD
Cette mĂ©thode ne demande que des informations sur la ressource, sans demander la ressource elle-mĂȘme.
POST
Cette mĂ©thode est utilisĂ©e pour transmettre des donnĂ©es en vue d'un traitement Ă  une ressource (le plus souvent depuis un formulaire HTML). L'URI fourni est l'URI d'une ressource Ă  laquelle s'appliqueront les donnĂ©es envoyĂ©es. Le rĂ©sultat peut ĂȘtre la crĂ©ation de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implĂ©mentation des mĂ©thodes HTTP (pour Ajax) par certains navigateurs (et la norme HTML qui ne supporte que les mĂ©thodes GET et POST pour les formulaires), cette mĂ©thode est souvent utilisĂ©e en remplacement de la requĂȘte PUT, qui devrait ĂȘtre utilisĂ©e pour la mise Ă  jour de ressources.
OPTIONS
Cette méthode permet d'obtenir les options de communication d'une ressource ou du serveur en général.
CONNECT
Cette méthode permet d'utiliser un proxy comme un tunnel de communication.
TRACE
Cette méthode demande au serveur de retourner ce qu'il a reçu, dans le but de tester et effectuer un diagnostic sur la connexion.
PUT
Cette méthode permet de remplacer ou d'ajouter une ressource sur le serveur. L'URI fourni est celui de la ressource en question.
PATCH
Cette méthode permet, contrairement à PUT, de faire une modification partielle d'une ressource.
DELETE
Cette méthode permet de supprimer une ressource du serveur.

Ces 3 derniÚres méthodes nécessitent généralement un accÚs privilégié.

Certains serveurs autorisent d'autres méthodes de gestion de leurs ressources (par exemple WebDAV).

Du client au serveur

La liaison entre le client et le serveur n'est pas toujours directe, il peut exister des machines intermédiaires servant de relais :

  • Un proxy (ou serveur mandataire) peut modifier les rĂ©ponses et requĂȘtes qu'il reçoit et peut gĂ©rer un cache des ressources demandĂ©es.
  • Une passerelle (ou gateway) est un intermĂ©diaire modifiant le protocole utilisĂ©.
  • Un tunnel transmet les requĂȘtes et les rĂ©ponses sans aucune modification, ni mise en cache.

Identification

HTTP permet l'identification du visiteur par transmission d'un nom et d'un mot de passe. Il existe 2 modes d'identification : Basic et Digest (RFC 2617[6]). Le premier mode transmet le mot de passe en clair, et ne doit donc ĂȘtre utilisĂ© qu'avec le protocole HTTPS. Le deuxiĂšme mode permet une identification sans transmettre le mot de passe en clair. L'identification est cependant souvent effectuĂ©e par une couche applicative supĂ©rieure Ă  HTTP.

Liste de serveurs HTTP

HTTP 0.9

Au dĂ©but du World Wide Web, il Ă©tait prĂ©vu d'ajouter au protocole HTTP des capacitĂ©s de nĂ©gociation de contenu, en s'inspirant notamment de MIME. En attendant, le protocole HTTP 0.9 Ă©tait extrĂȘmement simple.

  1. connexion du client HTTP
  2. envoi d'une requĂȘte de mĂ©thode GET
  3. réponse du serveur HTTP
  4. le serveur ferme la connexion pour signaler la fin de la réponse.

RequĂȘte :

GET /page.html

La mĂ©thode GET est la seule possible. Le serveur reconnaĂźt qu'il a affaire Ă  une requĂȘte HTTP 0.9 au fait que la version n'est pas prĂ©cisĂ©e Ă  la suite de l'URI.

RĂ©ponse :

      <TITLE>Exemple</TITLE>
      <H1>Exemple</H1>Ceci est une page d'exemple.

Pour rĂ©pondre Ă  une requĂȘte HTTP 0.9, le serveur envoie directement le contenu de la rĂ©ponse, sans mĂ©tadonnĂ©es. Il ne doit jamais se comporter ainsi pour les requĂȘtes HTTP de version supĂ©rieure.

Inutile de chercher les versions inférieures à 0.9 du protocole HTTP : elles n'existent pas, car HTTP 0.9 n'avait initialement pas de numéro de version. Il a fallu lui en attribuer un quand HTTP 1.0 est arrivé.

HTTP 1.0

Le protocole HTTP 1.0, dĂ©crit dans la RFC 1945[1], prĂ©voit l'utilisation d'en-tĂȘtes spĂ©cifiĂ©s dans la RFC 822[8]. La gestion de la connexion reste identique Ă  HTTP 0.9 : le client Ă©tablit la connexion, envoie une requĂȘte, le serveur rĂ©pond et ferme immĂ©diatement la connexion.

Une requĂȘte HTTP prĂ©sente le format suivant :

     Ligne de commande (Commande, URL, Version de protocole)
     En-tĂȘte de requĂȘte
     [Ligne vide]
     Corps de requĂȘte

Les réponses HTTP présentent le format suivant :

     Ligne de statut (Version, Code-réponse, Texte-réponse)
     En-tĂȘte de rĂ©ponse
     [Ligne vide]
     Corps de réponse

RequĂȘte :

GET /page.html HTTP/1.0
Host: example.com
Referer: http://example.com/
User-Agent: CERN-LineMode/2.15 libwww/2.17b3

La version du protocole HTTP est prĂ©cisĂ©e Ă  la suite de l'URI. La requĂȘte doit ĂȘtre terminĂ©e par un double retour Ă  la ligne (CRLFCRLF). HTTP 1.0 supporte aussi les mĂ©thodes HEAD et POST. On constate l'usage d'en-tĂȘtes inspirĂ©s de MIME pour transfĂ©rer les mĂ©tadonnĂ©es :

Host
Permet de prĂ©ciser le site web concernĂ© par la requĂȘte, ce qui est nĂ©cessaire pour un serveur hĂ©bergeant plusieurs sites Ă  la mĂȘme adresse IP (name based virtual host, hĂŽte virtuel basĂ© sur le nom). C'est le seul en-tĂȘte rĂ©ellement important.
Referer
Indique l'URI du document qui a donnĂ© un lien sur la ressource demandĂ©e. Cet en-tĂȘte permet aux webmasters d'observer d'oĂč viennent les visiteurs.
User-Agent
Indique le logiciel utilisé pour se connecter. Il s'agit généralement d'un navigateur web ou d'un robot d'indexation.

RĂ©ponse :

HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Server: Apache/0.8.4
Content-Type: text/html
Content-Length: 59
Expires: Sat, 01 Jan 2000 00:59:59 GMT
Last-modified: Fri, 09 Aug 1996 14:21:40 GMT
<TITLE>Exemple</TITLE>
<P>Ceci est une page d'exemple.</P>

La premiĂšre ligne donne le code de statut HTTP (200 dans ce cas).

Date
Moment auquel le message est généré.
Server
Indique quel modĂšle de serveur HTTP rĂ©pond Ă  la requĂȘte.
Content-Type
Indique le type MIME de la ressource.
Content-Length
Indique la taille en octets de la ressource.
Expires
Indique le moment aprĂšs lequel la ressource devrait ĂȘtre considĂ©rĂ©e obsolĂšte ; permet aux navigateurs Web de dĂ©terminer jusqu'Ă  quand garder la ressource en mĂ©moire cache.
Last-Modified
Indique la date de derniÚre modification de la ressource demandée.

HTTP 1.1

Le protocole HTTP 1.1 est dĂ©crit par le RFC 2616[3] qui rend le RFC 2068[2] obsolĂšte. La diffĂ©rence avec HTTP 1.0 est une meilleure gestion du cache. L'en-tĂȘte Host devient obligatoire dans les requĂȘtes.

Les soucis majeurs des deux premiĂšres versions du protocole HTTP sont d'une part le nombre important de connexions lors du chargement d'une page complexe (contenant beaucoup d'images ou d'animations) et d'autre part le temps d'ouverture d'une connexion entre client et serveur (l'Ă©tablissement d'une connexion TCP prend un temps triple de la latence entre client et serveur). Des expĂ©rimentations de connexions persistantes ont cependant Ă©tĂ© effectuĂ©es avec HTTP 1.0 (notamment par l'emploi de l'en-tĂȘte Connection: Keep-Alive), mais cela n'a Ă©tĂ© dĂ©finitivement mis au point qu'avec HTTP 1.1.

Par dĂ©faut, HTTP 1.1 utilise des connexions persistantes, autrement dit la connexion n'est pas immĂ©diatement fermĂ©e aprĂšs une requĂȘte, mais reste disponible pour une nouvelle requĂȘte. On appelle souvent cette fonctionnalitĂ© keep-alive. Il est aussi permis Ă  un client HTTP d'envoyer plusieurs requĂȘtes sur la mĂȘme connexion sans attendre les rĂ©ponses. On appelle cette fonctionnalitĂ© pipelining. La persistance des connexions permet d'accĂ©lĂ©rer le chargement de pages contenant plusieurs ressources, tout en diminuant la charge du rĂ©seau.

La gestion de la persistance d'une connexion est gĂ©rĂ©e par l'en-tĂȘte Connection.

HTTP 1.1 supporte la nĂ©gociation de contenu. Un client HTTP 1.1 peut accompagner la requĂȘte pour une ressource d'en-tĂȘtes indiquant quels sont les langues et formats de donnĂ©es prĂ©fĂ©rĂ©s. Il s'agit des en-tĂȘtes dont le nom commence par Accept-.

Les en-tĂȘtes supplĂ©mentaires supportĂ©s par HTTP 1.1 sont :

Connection
Cet en-tĂȘte peut ĂȘtre envoyĂ© par le client ou le serveur et contient une liste de noms spĂ©cifiant les options Ă  utiliser avec la connexion actuelle. Si une option possĂšde des paramĂštres ceux-ci sont spĂ©cifiĂ©s par l'en-tĂȘte portant le mĂȘme nom que l'option (Keep-Alive par exemple, pour spĂ©cifier le nombre maximum de requĂȘtes par connexion). Le nom close est rĂ©servĂ© pour spĂ©cifier que la connexion doit ĂȘtre fermĂ©e aprĂšs traitement de la requĂȘte en cours.
Accept
Cet en-tĂȘte liste les types MIME de contenu acceptĂ©s par le client. Le caractĂšre Ă©toile * peut servir Ă  spĂ©cifier tous les types / sous-types.
Accept-Charset
Spécifie les encodages de caractÚres acceptés.
Accept-Language
Spécifie les langues acceptées.

L'ordre de préférence de chaque option (type, encodage ou langue) est spécifié par le paramÚtre optionnel q contenant une valeur décimale entre 0 (inacceptable) et 1 (acceptable) inclus (3 décimales maximum aprÚs la virgule), valant 1 par défaut.

Le support des connexions persistantes doit Ă©galement fonctionner dans les cas oĂč la taille de la ressource n'est pas connue d'avance (ressource gĂ©nĂ©rĂ©e dynamiquement par le serveur, flux externe au serveur
).

Pour cela, l'encodage de transfert nommĂ© chunked permet de transmettre la ressource par morceaux consĂ©cutifs en prĂ©cĂ©dant chacun par une ligne de texte donnant la taille de celui-ci en hexadĂ©cimal. Le transfert se termine alors par un morceau de taille nulle, oĂč des en-tĂȘtes finaux peuvent ĂȘtre envoyĂ©s.

Les en-tĂȘtes supplĂ©mentaires liĂ©s Ă  cet encodage de transfert sont :

Transfer-Encoding
Spécifie l'encodage de transfert. La seule valeur définie par la spécification RFC 2616[3] est chunked.
Trailer
Liste tous les en-tĂȘtes figurant aprĂšs le dernier morceau transfĂ©rĂ©.
TE
EnvoyĂ© par le client pour spĂ©cifier les encodages de contenu supportĂ©s (Content-Encoding, ne pas confondre avec Transfer-Encoding car chunked est obligatoirement supportĂ© par les clients et serveurs implĂ©mentant le standard HTTP/1.1), et spĂ©cifie si le client supporte l'en-tĂȘte Trailer en ajoutant trailers Ă  la liste.

HTTP 1.1 bis

RFC 2616[3] comprenait de nombreuses imprécisions. Le groupe de travail HTTP a pris quelques années afin de clarifier la spécification sans en modifier la sémantique tel que préconisé dans la charte de fonctionnement du groupe pour ce travail. En , 8 nouveaux documents ont été publiés qui rendent obsolÚte la RFC 2616[3] :

  • RFC 7230[4] Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (Standard proposĂ©)
  • RFC 7231[9] Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Standard proposĂ©)
  • RFC 7232[10] Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (Standard proposĂ©)
  • RFC 7233[11] Hypertext Transfer Protocol (HTTP/1.1): Range Requests (Standard proposĂ©)
  • RFC 7234[12] Hypertext Transfer Protocol (HTTP/1.1): Caching (Standard proposĂ©)
  • RFC 7235[13] Hypertext Transfer Protocol (HTTP/1.1): Authentication (Standard proposĂ©)
  • RFC 7236[14] Hypertext Transfer Protocol (HTTP/1.1): Authentication Scheme Registrations (Information)
  • RFC 7237[5] Hypertext Transfer Protocol (HTTP/1.1): Method Registrations (Information)

HTTP/2

Une nouvelle version d'HTTP, HTTP/2, a été développée au sein du groupe de travail « Hypertext Transfer Protocol Bis » (httpbis) de l'Internet Engineering Task Force[15], et approuvée comme RFC standard le [16]. Le développement d'HTTP/2 a débuté à la suite de la création du protocole SPDY proposé par Google afin de réduire le temps de chargement des pages Web[17] - [18]. Le groupe de travail httpbis s'était initialement interdit de proposer une nouvelle version d'HTTP, concentrant son activité sur la clarification des spécifications d'HTTP 1.1. Considérant l'arrivée de SPDY et son adoption rapide sur le Web, avec notamment des implémentations dans deux des principaux navigateurs Web, Google Chrome et Mozilla Firefox, Mark Nottingham, « chair » d'httpbis, a émis l'opinion qu'il était temps d'envisager HTTP/2 et proposé d'amender la charte d'httpbis en ce sens, initiant de fait le développement du nouveau protocole[19].

SPDY constituait une option naturelle pour servir de base Ă  HTTP/2. Deux autres propositions concurrentes ont Ă©tĂ© ensuite transmises Ă  l'IETF : le protocole « HTTP Speed+Mobility » par Microsoft[20] et une proposition de mise Ă  jour d'HTTP (« Network-Friendly HTTP Upgrade »)[21]. En , httpbis a publiĂ© un appel Ă  expression d'intĂ©rĂȘt (« Call for Expression of Interest ») afin de recueillir l'avis d'acteurs du Web sur les propositions[22]. Parmi les rĂ©ponses obtenues figure celle de Facebook qui a signifiĂ© sa prĂ©fĂ©rence pour SPDY[23]. En , l'IETF a publiĂ© le premier draft d'HTTP/2, qui est une copie directe de SPDY[24].

AprÚs plus de 2 ans de discussions, la RFC est approuvée en par le groupe de pilotage de l'IETF, et est publiée en .

Le module permettant la prise en charge du protocole HTTP/2 est disponible depuis la version 2.4.17[25] du serveur Web Apache, et depuis la version 1.9.5[26] de Nginx.

HTTP/3

Une nouvelle version d’HTTP, HTTP/3, est la troisiĂšme et prochaine version majeure du protocole de transfert hypertexte utilisĂ© pour Ă©changer des informations sur le World Wide Web. Celle-ci repose sur le protocole QUIC, dĂ©veloppĂ© par Google en 2012.

La sĂ©mantique HTTP est cohĂ©rente d'une version Ă  l'autre. En effet, les mĂȘmes mĂ©thodes de requĂȘte, codes de statut et champs de message sont gĂ©nĂ©ralement applicables Ă  toutes les versions.

Si HTTP/1 et HTTP/2 utilisent tous deux TCP comme protocole de transport, HTTP/3 quant Ă  lui utilise le protocole QUIC, un protocole de la couche transport qui est plus adaptĂ© au Web. Le passage Ă  QUIC vise Ă  rĂ©soudre un problĂšme majeur de HTTP/2 appelĂ© "Head-of-line Blocking" grĂące Ă  une encapsulation des paquets dans UDP. En effet, avec HTTP/2 reposant sur TCP, une connexion permet d'accĂ©der aux ressources demandĂ©es une Ă  une (une seule Ă  la fois). Lorsque l'envoi d’une ressource est perturbĂ© (par exemple par une perte de paquets), la livraison globale des ressources est ralentie. Avec HTTP/3 reposant sur le protocole QUIC, ce problĂšme n'est plus, puisque tous les flux sont indĂ©pendants Ă©tant encapsulĂ©s dans UDP, protocole de transport ne nĂ©cessitant pas de connexion.

Notes et références

  1. (en) Request for comments no 1945.
  2. (en) Request for comments no 2068.
  3. (en) Request for comments no 2616.
  4. (en) Request for comments no 7230.
  5. (en) Request for comments no 7237.
  6. (en) Request for comments no 2617.
  7. https://github.com/macournoyer/thin
  8. (en) Request for comments no 822.
  9. (en) Request for comments no 7231.
  10. (en) Request for comments no 7232.
  11. (en) Request for comments no 7233.
  12. (en) Request for comments no 7234.
  13. (en) Request for comments no 7235.
  14. (en) Request for comments no 7236.
  15. (en) « Hypertext Transfer Protocol Bis (httpbis) », sur datatracker.ietf.org (consulté le )
  16. (en) « HTTP/2 Approved », sur www.ietf.org (consulté le )
  17. (en) « SPDY: An experimental protocol for a faster web » (consulté le )
  18. « SPDY Protocol (Internet draft) »,
  19. (en) Mark Nottingham, « Rechartering HTTPbis », sur lists.w3.org, (consulté le )
  20. (en) « HTTP Speed+Mobility (Internet draft) »,
  21. (en) « Proposal for a Network-Friendly HTTP Upgrade »,
  22. (en) « Call for Expressions of Interest », sur ietf.org,
  23. (en) « HTTP2 Expression of Interest »,
  24. (en) Dio Synodinos, « HTTP 2.0 First Draft Published », sur InfoQ,
  25. « Apache Module mod_http2 », sur https://httpd.apache.org/
  26. (en-US) « HTTP/2 Supported in Open Source NGINX 1.9.5 », sur NGINX, (consulté le )

Voir aussi

Articles connexes

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplĂ©mentaires peuvent s’appliquer aux fichiers multimĂ©dias.