Le Protocole HTTP


précédentsommairesuivant

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 riches en informations. Le format est :

 
Sélectionnez
{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'un 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 utilsé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ées 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 principales en-têtes utilisées lors des réponses.

  • Content-type et Content-length
    Ces deux en-têtes sont censées 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. Si elles ne sont pas indiquées, c'est le client qui est seul responsable de leur éventuelle valeur par défaut.

  • Location
    Cette en-tête permet d'indiquer une redirection. A 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
    Cette 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és entre elles et de celui-ci par un point-virgule.

  • D'autres en-têtes
    Bien sûr, toutes les en-têtes ne sont pas listées ici. Vous trouverez sûrement une description exhaustive dans la RFC.

précédentsommairesuivant

Vous avez aimé ce tutoriel ? Alors partagez-le en cliquant sur les boutons suivants : Viadeo Twitter Facebook Share on Google+   

  

Copyright © 2006 Mathieu Lemoine. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.