Cours : Le protocole HTTP

GET

GET est probablement la méthode la plus couramment utilisée, elle permet de demander à accéder à une ressource et son contenu.

Dans cet exemple, je demande à ce que l'on m'envoie le contenu de la page d'accueil de Google :

HEAD

HEAD demande des informations sur la ressource, sans demander la ressource elle-même.

Parmi les informations utiles que peut vous transmettre HEAD il y a Content-Length qui vous permet de connaître la taille d'un contenu avant de lancer une requête GET lourde si la ressource est volumineuse.

POST

POST permet de transmettre des données, son usage le plus classique aujourd'hui est au sein des formulaires HTML. Quand vous remplissez un formulaire HTML qui a comme attribut method=post c'est elle qui sera appelée.

OPTIONS

OPTIONS permet de récupérer la liste des options de communication disponibles pour une ressource ou un serveur : Les méthodes disponibles, si une autorisation est nécessaire, le format de données attendu, ...

CONNECT

CONNECT permet d'utiliser un intermédiaire, appelé proxy pour accéder aux ressources.

TRACE

TRACE peut être considérée comme une méthode de debug ou de diagnostic, elle demande au serveur de retourner exactement ce qu'il a reçu.

PUT

PUT permet de remplacer ou ajouter une ressource sur un serveur. Comme les formulaires HTML n'acceptent que GET et POST, elle est très souvent remplacée par POST.

PATCH

PATCH permet de modifier partiellement une ressource, sans avoir à la remplacer totalement (contrairement à PUT).

QUERY

QUERY est la plus récente des méthodes, c'est une sorte de POST qui envoie des données pour traitement, mais qui contrairement à POST ne fait pas de modification sur le serveur.

DELETE

DELETE demande à supprimer une ressource du serveur.

Les en-têtes dans une requête

Quand vous faites une requête HTTP, les en-têtes voyagent après la première ligne (méthode + URI + version) et avant le corps (s'il y en a un) :

Les en-têtes Content-Type et Accept sont particulièrement importants : ils disent au serveur ce que vous envoyez (Content-Type) et ce que vous attendez (Accept). C'est ce qu'on appelle la négociation de contenu.

Les en-têtes dans une réponse

Le serveur renvoie ses propres en-têtes avant le corps de la réponse :

Ici, le serveur indique que la ressource a été créée (201 Created), quel format elle retourne (Content-Type), où la trouver (Location, utile pour les redirects ou la création de ressources) et qu'il positionne un cookie de session.

À retenir sur les en-têtes

• Ils ne font pas partie du corps de la requête ou de la réponse

• Le champ Host est toujours obligatoire (quel que soit la version d'HTTP), les autres le sont moins

• Le client et le serveur peuvent en ajouter autant qu'ils veulent, tant que chacun les comprend

À l'origine

Dans ses premières versions, HTTP nécessitait de rouvrir une connexion pour chaque requête, le processus ressemblait à ceci :

1. Le client ouvre la connexion

2. Le client envoie sa requête

3. Le serveur envoie sa réponse

4. Le serveur ferme la connexion

Sécurisé mais peu pratique.

Aujourd'hui

1. Le client ouvre la connexion en indiquant de la maintenir ouverte Keep-Alive

2. Le client envoie sa première requête

3. Le serveur envoie la réponse à la première requête

4. Le client envoie la seconde requête

5. Le serveur envoie la réponse à la seconde requête

6. ...

7. Le client (Connection: close) ou le serveur (Connection : timeout) ferme la connexion

Exemple

Dans cet exemple je veux récupérer les infos sur une ressource pour vérifier sa taille avant de lancer la récupération de cette ressource :

Le client ouvre la connexion vers le serveur.

Le client envoie une requête HEAD pour récupérer les informations de la ressource :

Le serveur envoie la réponse avec les informations sur document.pdf:

Le client envoie une requête GET pour récupérer document.pdf:

Le serveur envoie la réponse avec le contenu de document.pdf:

200

Un code 200 signifie que tout s'est passé normalement.

300

Un code 301 ou 302 signifie que la requête a dû être redirigée.

400

Les codes 400 sont des codes d'erreur (et généralement le problème vient du client):

• 401 : utilisateur non authentifié

• 403 : accès refusé (vous êtes peut être authentifié mais n'avez pas les droits nécessaires par exemple)

• 404 : ressource non trouvée (la fameuse page 404)

500

Les codes 500 sont des codes d'erreur et généralement le problème vient du serveur :

• 500, 502 et 503 : erreur du côté du serveur (souvent vous návez pas plus de précision)

• 504 : le serveur n'a pas répondu.

Le meilleur d'entre tous

En 1998 un code avait été annoncé pour le 1er avril : 418 : Je suis une théière. Le problème, c'est que la blague a tellement perduré qu'on a estimé que ce code ne pourrait pas servir pour quelque chose de sérieux, il a donc été officiellement adopté. Il sert spécifiquement pour une théière à signifier qu'elle ne peut pas faire de café, puisqu'elle est une théière.