III. Les réponses HTTP▲
Quand le serveur a fini de recevoir la requête, il la traite et renvoie la réponse appropriée (éventuellement une erreur).
Les réponses sont bâties sur un modèle similaire à celui des requêtes. Voyons leurs spécificités.
III-A. La ligne d'Introduction▲
Les lignes d'Introduction des réponses HTTP ont une structure plus simple que celle des requêtes, mais tout aussi riche en informations. Le format est :
{Version}{SP}{Code Status}{SP}{Phrase Status}La Version est la même que pour la requête.
Le Code Status est un code sur trois chiffres qui indique le status de la requête. Nous y reviendrons plus tard.
Le séparateur SP est un espace.
La Phrase Status est simplement une phrase permettant de rendre le status plus lisible pour un humain. Elle est purement indicative et n'a aucune valeur informative sur le plan du protocole, elle est d'ailleurs facultative. Nous indiquerons cependant les Phrases Status (Reason Phrase) proposées par les RFC pour les codes que nous détaillerons.
Les Codes Status sont regroupés en familles, qui sont au nombre de cinq pour les versions 1.0 et 1.1 de HTTP. La famille est indiquée par le premier chiffre du code (celui des centaines), il va de 1 à 5.
Tout code inconnu doit être traité par le client comme le code de base de la famille (X00) et être présenté à l'utilisateur.
Si la famille est inconnue, le code doit être traité comme un code Erreur Serveur (famille 5xx) et être indiqué à l'utilisateur.
Informations : les 1xx▲
Ces codes sont là simplement pour permettre au serveur d'envoyer une notification.
- 100 Continue
Ce code status est rarement utilisé et informe simplement que la partie de la requête qui a déjà été reçue est valide. Il n'est pas envoyé par défaut, mais seulement dans des cas précis. - 101 Switching protocol
Ce code status permet de changer le protocole ou la version du protocole utilisé lors de la communication. Le nouveau protocole à utiliser est spécifié par l'en-tête Upgrade.
Succès : les 2xx▲
Ces codes indiquent que tout s'est bien déroulé et que la ressource demandée est renvoyée.
- 200 OK
Tout est bon, c'est la réponse la plus souvent employée. - 201 Created
Peut être utilisé par exemple dans le cadre d'une requête PUT pour indiquer que le document a bien été uploadé. - 204 No Content
La requête s'est bien déroulée, mais le corps de la réponse est vide. - 206 Partial Content
Ce code est généralement utilisé dans le cadre d'une récupération de téléchargement, ou de l'utilisation du cache. Seule une partie du document demandé est renvoyée.
Redirection : les 3xx▲
Ces codes indiquent que la ressource demandée n'est plus à l'emplacement indiqué. Ils sont très utilisés pour les redirections. L'en-tête, accompagnant la redirection et qui indique le nouvel emplacement de la ressource, est alors l'en-tête Location.
- 300 Multiple Choice
Ce code est utilisé quand on peut trouver plusieurs versions de la ressource (différence de format ou de langue par exemple). - 301 Moved Permanently
Quand une ressource est déplacée définitivement, c'est ce code qui permet d'indiquer le déplacement notamment aux moteurs de recherche. La requête ayant généré l'erreur doit alors être renvoyée pour correspondre avec la nouvelle ressource. - 307 Temporary Redirect
Ce code permet d'indiquer une redirection temporaire.
Requête Invalide : les 4xx▲
Ces codes indiquent une erreur de la part du client, ressource invalide, authentification invalide, etc. La requête doit alors être modifiée et éventuellement retransmise pour pouvoir être traitée.
- 400 Bad Request
Erreur générique. - 401 Unauthorized ou Authorization required
Le client n'est pas censé avoir accès à la requête au vu de son niveau actuel d'identification. Il doit s'identifier de manière correcte. S'il ne peut remplir les conditions d'identification, alors les requêtes suivantes aboutiront à une erreur 403. - 403 Forbidden
La ressource est interdite au client. - 404 Not Found
La fameuse erreur 404, elle indique que la ressource demandée n'a pu être trouvée. - 405 Method Not Allowed
Le client n'est pas censé pouvoir envoyer ce type de requête, une authentification est certainement nécessaire.
Erreur Serveur : les 5xx▲
Ces codes sont utilisés en cas d'erreur de la part du serveur, en cas de surcharge, d'erreur de configuration, etc. Le plus simple est d'attendre un peu et de retenter plus tard : si l'erreur persiste, contactez l'administrateur du serveur.
- 500 Internal Server Error
Erreur Interne au serveur, il n'est pas en état de répondre actuellement. - 501 Not Implemented
Certaines fonctionnalités requises par les en-têtes ou la méthode employés ne sont pas supportées par le serveur. - 503 Service Unavaible
Utilisé par exemple quand le serveur est surchargé. - 505 HTTP Version Not Supported
Le serveur ne supporte pas la version du protocole HTTP qui a été utilisée.
D'autres codes status▲
Tous les codes n'ont bien entendu pas été listés ici, certains ont même été invalidés lors du passage de HTTP/1.0 à HTTP/1.1 (306 par exemple), ou bien sont réservés pour des versions ultérieures du protocole (402 par exemple).
III-B. Les en-têtes de réponse▲
Voici les principaux en-têtes utilisés lors des réponses.
- Content-type et Content-length
Ces deux en-têtes sont censés indiquer le type MIME et la taille en octets du corps de la réponse. De plus, l'en-tête Content-type peut indiquer le charset utilisé dans le corps de la réponse (dans le cadre d'un type texte). Il est alors indiqué par la mention "charset=" suivie du nom du charset. Il suit le type MIME, en est séparé par un point-virgule. S'ils ne sont pas indiqués, c'est le client qui est seul responsable de leur éventuelle valeur par défaut. - Location
Cet en-tête permet d'indiquer une redirection. À sa réception, le client est généralement censé renvoyer une requête sur l'adresse indiquée. Ce comportement dépend du code status renvoyé avec la réponse. - Set-Cookie
Cet en-tête permet d'indiquer au client des cookies à stocker. Sa valeur peut prendre une forme assez complexe. La forme par défaut est celle de l'en-tête de requête Cookie. Les formes plus évoluées consistent à l'indication d'informations telles que : la date de péremption (Expires), le domaine d'application (Domain), le chemin d'application (Path), etc. Toutes ces informations sont indiquées à la suite du couple nom/valeur de la même manière (nom de l'information, égal, valeur) et séparées entre elles et de celui-ci par un point-virgule. - D'autres en-têtes
Bien sûr, tous les en-têtes ne sont pas listés ici. Vous trouverez sûrement une description exhaustive dans la RFC.