Aller au contenu

Hypertext Transfer Protocol

Un article de Wikipédia, l'encyclopédie libre.
(Redirigé depuisProtocole HTTP)

HTTP

Page d’aide sur l’homonymie

Ne doit pas être confondu avecHypertext Transfer Protocol Secure.

Hypertext Transfer Protocol
Logiciel
Début d'uneadresse webHTTP dans labarre d'adressed'unnavigateur web.
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

modifier

L’Hypertext Transfer Protocol,généralement abrégéHTTP,littéralement « protocole de transferthypertexte», est unprotocole de communicationclient-serveurdéveloppé pour leWorld Wide Web.HTTPS(avec S poursecure,soit « sécurisé ») est la variante sécurisée par lechiffrementet l'authentification.

HTTP est avecHTMLet lesURLune des trois inventions fondamentales deTim Berners-Leepour créer leWorld Wide Web.

Lesclients HTTPles plus connus sont lesnavigateurs Web.HTTP est aussi utilisé hors du Web pour mettre en œuvre lesinterfaces de programmationdistribuée fondées surSOAPetREST.

Historique

[modifier|modifier le code]
Article détaillé:World Wide Web#Histoire.

HTTP a été inventé parTim Berners-Leeavec lesadresses Webet le langageHTMLpour créer leWorld Wide Web.À cette époque, leFile Transfer Protocol(FTP) était déjà disponible pour transférer des fichiers, mais il ne supportait pas la notion deformat de donnéestelle qu'introduite parMultipurpose 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,laRFC1945[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 laRFC2068[2]de l'IETF, puis dans laRFC2616[3]en.Cette version ajoute le support du transfert enpipeline(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êteHostobligatoire 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,RFC7230[4]àRFC7237[5].

Implémentation

[modifier|modifier le code]

Méthodes

[modifier|modifier le code]
Capture d'écran d'une requête GET et de sa réponse.

Dans le protocole HTTP, une méthode est unecommandespé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'URLqui 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'URIfourni 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 (pourAjax) par certains navigateurs (et la normeHTMLqui 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 modificationpartielled'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 exempleWebDAV).

Du client au serveur

[modifier|modifier le code]

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

  • Unproxy(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.
  • Unepasserelle(ougateway) est un intermédiaire modifiant le protocole utilisé.
  • Untunneltransmet les requêtes et les réponses sans aucune modification, ni mise en cache.

Identification

[modifier|modifier le code]

HTTP permet l'identificationdu visiteur par transmission d'un nom et d'unmot de passe. Il existe deux modes d'identification:BasicetDigest(RFC2617[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

[modifier|modifier le code]
Article détaillé:Serveur HTTP.

Versions

[modifier|modifier le code]

HTTP 0.9

[modifier|modifier le code]

Au début duWorld Wide Web,il était prévu d'ajouter au protocole HTTP des capacités de négociation de contenu, en s'inspirant notamment deMIME.En attendant, le protocole HTTP 0.9 était extrêmement simple.

  1. connexion duclient HTTP
  2. envoi d'une requête de méthodeGET
  3. réponse duserveur HTTP
  4. le serveur ferme la connexion pour signaler la fin de la réponse

Requête: 

GET /page.html

La méthodeGETest 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

[modifier|modifier le code]

Le protocole HTTP 1.0, décrit dans laRFC1945[1],prévoit l'utilisation d'en-têtesspécifiés dans laRFC822[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 deMIMEpour transférer les métadonnées:

Host
Permet de préciser lesite webconcerné par la requête, ce qui est nécessaire pour un serveur hébergeant plusieurs sites à la mêmeadresse 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'URIdu document qui a donné un lien sur la ressource demandée. Cet en-tête permet auxwebmastersd'observer d'où viennent les visiteurs.
User-Agent
Indique le logiciel utilisé pour se connecter. Il s'agit généralement d'unnavigateur webou d'unrobot 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 lecode de statut HTTP(200 dans ce cas).

Date
Moment auquel le message est généré.
Server
Indique quel modèle deserveur HTTPrépond à la requête.
Content-Type
Indique le typeMIMEde la ressource.
Content-Length
Indique la taille enoctetsde 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 enmémoire cache.
Last-Modified
Indique la date de dernière modification de la ressource demandée.

HTTP 1.1

[modifier|modifier le code]

Le protocole HTTP 1.1 est décrit par leRFC2616[3]qui rend leRFC2068[2]obsolète. La différence avec HTTP 1.0 est une meilleure gestion du cache. L'en-têteHostdevient 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 TCPprend 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êteConnection: 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êteConnection.

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 leslanguesetformats de donnéespréférés. Il s'agit des en-têtes dont le nom commence parAccept-.

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-Alivepar exemple, pour spécifier le nombre maximum de requêtes par connexion). Le nomcloseest 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 optionnelqcontenant 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…).

Article détaillé:Chunked transfer encoding.

Pour cela, l'encodage de transfert nomméchunkedpermet 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écificationRFC2616[3]estchunked.
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 avecTransfer-Encodingcarchunkedest obligatoirement supporté par les clients et serveurs implémentant le standard HTTP/1.1), et spécifie si le client supporte l'en-têteTraileren ajoutanttrailersà la liste.

HTTP 1.1 bis

[modifier|modifier le code]

RFC2616[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,huit nouveaux documents ont été publiés qui rendent obsolète laRFC2616[3]:

  • RFC7230[4]Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing (Standard proposé)
  • RFC7231[9]Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content (Standard proposé)
  • RFC7232[10]Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests (Standard proposé)
  • RFC7233[11]Hypertext Transfer Protocol (HTTP/1.1): Range Requests (Standard proposé)
  • RFC7234[12]Hypertext Transfer Protocol (HTTP/1.1): Caching (Standard proposé)
  • RFC7235[13]Hypertext Transfer Protocol (HTTP/1.1): Authentication (Standard proposé)
  • RFC7236[14]Hypertext Transfer Protocol (HTTP/1.1): Authentication Scheme Registrations (Information)
  • RFC7237[5]Hypertext Transfer Protocol (HTTP/1.1): Method Registrations (Information)

HTTP/2

[modifier|modifier le code]
Article détaillé:Hypertext Transfer Protocol/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 protocoleSPDYproposé parGoogleafin 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 principauxnavigateurs Web,Google ChromeetMozilla 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 » parMicrosoft[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 deFacebookqui 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 deux ans de discussions, la RFC est approuvée enpar 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

[modifier|modifier le code]

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 protocoleQUIC,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 protocoleQUIC,un protocole de la couche transport qui est plus adapté au Web. Le passage àQUICvise à 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 protocoleQUIC,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

[modifier|modifier le code]
  1. ↑aetb(en)Request for commentsno1945
  2. ↑aetb(en)Request for commentsno2068
  3. ↑abcdete(en)Request for commentsno2616
  4. ↑aetb(en)Request for commentsno7230
  5. ↑aetb(en)Request for commentsno7237
  6. ↑(en)Request for commentsno2617
  7. ↑(en)«Macournoyer/thin: A very fast & simple Ruby web server», surGitHub(consulté le).
  8. ↑(en)Request for commentsno822
  9. ↑(en)Request for commentsno7231
  10. ↑(en)Request for commentsno7232
  11. ↑(en)Request for commentsno7233
  12. ↑(en)Request for commentsno7234
  13. ↑(en)Request for commentsno7235
  14. ↑(en)Request for commentsno7236
  15. ↑(en)«Hypertext Transfer Protocol Bis (httpbis)», surdatatracker.ietf.org(consulté le).
  16. ↑(en)«HTTP/2 Approved», surietf.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», surlists.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», surietf.org,.
  23. ↑(en)«HTTP2 Expression of Interest»,.
  24. ↑(en)Dio Synodinos, «HTTP 2.0 First Draft Published», surInfoQ,.
  25. ↑«Apache Module mod_http2», surhttpd.apache.org.
  26. ↑(en-US)«HTTP/2 Supported in Open Source NGINX 1.9.5», surNGINX,(consulté le).

Voir aussi

[modifier|modifier le code]

Articles connexes

[modifier|modifier le code]

Liens externes

[modifier|modifier le code]
v·m
7.Application
6.Présentation
5.Session
4.Transport
3.Réseau
2.Liaison
1.Physique
v·m
Officiel
Non-officiel
v·m
Contexte
Semantic Web Stack
Applicationset interfaces
Triplestore
Règles
Structure
Requête
Échange
Syntaxe
Identifiant
Caractères
Autres ontologies
Articles liés
Ce document provient de «https://fr.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=219610567».