Une session HTTP typique

Dans les protocoles client-serveur, comme HTTP, les sessions se composent de trois phases :

  1. Le client établit une connexion TCP (ou la connexion appropriée si la couche de transport n'est pas TCP).
  2. Le client envoie sa requĂȘte et attend la rĂ©ponse.
  3. Le serveur traite la requĂȘte, renvoyant sa rĂ©ponse, fournissant un code d'Ă©tat et des donnĂ©es appropriĂ©es.

À partir de HTTP / 1.1, la connexion n'est plus fermĂ©e aprĂšs avoir terminĂ© la troisiĂšme phase, et le client peut Ă  nouveau effectuer une requĂȘte : cela signifie que la deuxiĂšme et la troisiĂšme phases peuvent maintenant ĂȘtre effectuĂ©es Ă  tout moment.

Établir une connexion

Dans les protocoles client-serveur, c'est le client qui établit la connexion. L'ouverture d'une connexion en HTTP signifie l'initiation d'une connexion dans la couche de transport sous-jacente, généralement TCP.

Avec TCP, le port par dĂ©faut, pour un serveur HTTP sur un ordinateur, est le port 80. D'autres ports peuvent Ă©galement ĂȘtre utilisĂ©s, comme 8000 ou 8080. L'URL d'une page Ă  rĂ©cupĂ©rer contient Ă  la fois le nom de domaine et le numĂ©ro de port, Ce dernier peut ĂȘtre omis s'il en est Ă  80. Voir Identifying resources on the Web pour plus de details.

Note: Le modÚle client-serveur n'autorise pas le serveur à envoyer des données au client sans une demande explicite. Pour contourner ce problÚme, les développeurs Web utilisent plusieurs techniques: effectuer un ping sur le serveur périodiquement via le XMLHTTPRequest, Fetch API, en utilisant le HTML WebSockets API, ou des protocoles similaires.

Envoi d'une demande client

Une fois la connexion Ă©tablie, l'agent utilisateur peut envoyer la demande (un agent utilisateur est gĂ©nĂ©ralement un navigateur Web, mais peut ĂȘtre autre chose, un robot d'exploration, par exemple). Une demande de client consiste en des directives de texte, sĂ©parĂ©es par CRLF (retour de chariot, suivi d'une alimentation en ligne), divisĂ© en trois blocs :

  1. La premiÚre ligne contient une méthode de demande suivie de ses paramÚtres:
    • le chemin d'accĂšs du document, c'est-Ă -dire une URL absolue sans le protocole ou le nom de domaine
    • la version du protocole HTTP
  2. Les lignes subsĂ©quentes reprĂ©sentent un en-tĂȘte HTTP, ce qui donne aux informations du serveur quel type de donnĂ©es est appropriĂ© (par exemple, quelle langue, quels types MIME) ou d'autres donnĂ©es modifient son comportement (par exemple, ne pas envoyer de rĂ©ponse s'il est dĂ©jĂ  mis en cache). Ces en-tĂȘtes HTTP forment un bloc qui se termine par une ligne vide.
  3. Le bloc final est un bloc de données facultatif, qui peut contenir d'autres données principalement utilisées par la méthode POST.

Demandes d'exemple

Obtenir la page racine de developer.mozilla.org, c'est-à-dire http://developer.mozilla.org/, et dire au serveur que l'utilisateur-agent préférerait la page en français si possible :

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr

Observez cette derniĂšre ligne vide, ceci sĂ©pare le bloc de donnĂ©es du bloc d'en-tĂȘte. Comme il n'y a pas de Content-Length fourni dans un en-tĂȘte HTTP, ce bloc de donnĂ©es est prĂ©sentĂ© vide, marquant la fin des en-tĂȘtes, permettant au serveur de traiter la demande le moment oĂč elle reçoit cette ligne vide.

Par exemple, en envoyant le résultat d'un formulaire :

POST /contact_form.php HTTP/1.1
Host: developer.mozilla.org
Content-Length: 64
Content-Type: application/x-www-form-urlencoded

name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue

MĂ©thodes de demande

HTTP dĂ©finit un ensemble de mĂ©thodes de requĂȘte indiquant l'action souhaitĂ©e Ă  effectuer sur une ressource. Bien qu'ils puissent Ă©galement ĂȘtre des noms, ces mĂ©thodes de requĂȘtes sont parfois appelĂ©es verbes HTTP. Les requĂȘtes les plus courantes sont GET et POST :

  • La mĂ©thode GET demande une reprĂ©sentation de donnĂ©es de la ressource spĂ©cifiĂ©e. Les requĂȘtes utilisant GET ne doivent que rĂ©cupĂ©rer les donnĂ©es.
  • La mĂ©thode POST envoie des donnĂ©es Ă  un serveur afin qu'il puisse changer son Ă©tat. C'est la mĂ©thode souvent utilisĂ©e pour les formulaires HTML.

Structure d'une réponse du serveur

Une fois que l'agent connectĂ© a envoyĂ© sa requĂȘte, le serveur Web le traite et finalement renvoie une rĂ©ponse. Similaire Ă  une demande de client, une rĂ©ponse de serveur est formĂ©e de directives de texte, sĂ©parĂ©es par CRLF, mais divisĂ©es en trois blocs :

  1. La premiÚre ligne, la ligne d'état, consiste en une reconnaissance de la version HTTP utilisée, suivie d'une demande d'état (et sa brÚve signification dans un texte lisible par l'homme).
  2. Les lignes suivantes reprĂ©sentent des en-tĂȘtes HTTP spĂ©cifiques, en donnant aux clients des informations sur les donnĂ©es envoyĂ©es (par exemple, type, taille de donnĂ©es, algorithme de compression utilisĂ©, conseils sur la mise en cache). De la mĂȘme maniĂšre que le bloc d'en-tĂȘtes HTTP pour une demande de client, ces en-tĂȘtes HTTP forment un bloc se terminant par une ligne vide.
  3. Le dernier bloc est un bloc de données, qui contient les données facultatives.

Examples de réponses

Réponse réussie de la page Web :

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

Notification selon laquelle la ressource demandée a été définitivement déplacé ( en permanence ) :

HTTP/1.1 301 Moved Permanently
Server: Apache/2.2.3 (Red Hat)
Content-Type: text/html; charset=iso-8859-1
Date: Sat, 09 Oct 2010 14:30:24 GMT
Location: https://developer.mozilla.org/ (this is the new link to the resource; it is expected that the user-agent will fetch it)
Keep-Alive: timeout=15, max=98
Accept-Ranges: bytes
Via: Moz-Cache-zlb05
Connection: Keep-Alive
X-Cache-Info: caching
X-Cache-Info: caching
Content-Length: 325 (the content contains a default page to display if the user-agent is not able to follow the link)

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
<hr>
<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
</body></html>

Notification selon laquelle la ressource demandée n'existe pas :

HTTP/1.1 404 Not Found
Date: Sat, 09 Oct 2010 14:33:02 GMT
Server: Apache
Last-Modified: Tue, 01 May 2007 14:24:39 GMT
ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
Accept-Ranges: bytes
Content-Length: 10732
Content-Type: text/html

<!DOCTYPE html... (contains a site-customized page helping the user to find the missing resource)

Codes d'état de réponse

Les codes d'Ă©tat de rĂ©ponse HTTP indiquent si une requĂȘte HTTP spĂ©cifique a Ă©tĂ© effectuĂ©e avec succĂšs. Les rĂ©ponses sont regroupĂ©es en cinq classes: rĂ©ponses d'information, rĂ©ponses rĂ©ussies, redirections, erreurs de client et erreurs de serveurs.

  • 200: OK. La demande a rĂ©ussi.
  • 301: Moved Permanently. Ce code de rĂ©ponse signifie que l'URL de la ressource demandĂ©e a Ă©tĂ© modifiĂ©e.
  • 404: Not Found. Le serveur ne peut pas trouver la ressource demandĂ©e.

Voir aussi