RFC du protocole HTTP : Définition des codes d'état

Tous les codes d'état actuellement valides sont décrits ci-dessous, en précisant quelle méthode peut en être l'origine, ainsi que les métainformations à fournir dans la réponse.

9.1 Information 1xx

Cette classe de réponse est actuellement réservée pour de futures applications, et consiste en des messages avec une ligne d'état, des champs d'en-têtes éventuels, et terminés par une ligne vide (CRLFCRLF).

HTTP/1.0 ne définit actuellement aucun de ces codes, lesquels ne constituent pas une réponse valide à des requêtes HTTP/1.0. Il restent cependant exploitables à titre expérimental, dépassant le contexte de la présente spécification.

9.2 Succès 2xx

Cette classe précise que la requête du client a été correctement transmise, interprétée, et exécutée.

200 OK

La requête a abouti. L'information retournée en réponse dépend de la requête émise, comme suit:

GET

Une entité correspondant à l'URI visée par la requête est renvoyée au client;

HEAD

La réponse au client ne doit contenir que les champs d'en-tête à l'xclusion de tout corps d'entité;

POST

Une entité décrivant le résultat de l'action entreprise.

201 Créé

La requête a abouti, et une nouvelle ressource réseau en résulte.

La nouvelle ressource créée est accessible par l'URI(s) renvoyée dans l'entité de la réponse. La ressource doit être créée avant que ce code ne soit envoyé. Si la création ne peut pas être opérée immédiatement, le serveur devra indiquer dans la réponse quand la ressource deviendra disponible ou retourner un message de type 202 (acceptée).

Actuellement, seule la méthode POST peut conduire à la création d'une ressource.

202 Acceptée

La requête a été reçue et interprétée correctement, mais son traitement n'est pas terminé. La requête peut ou ne peut être réémise pendant le traitement, suivant que le serveur autorise ou n'autorise pas un arrêt du processus en cours. Il n'est pas possible de réémettre un code d'état dans ce type d'opération asynchrone.

La réponse 202 est intentionnellement non bloquante. Son rôle est de permettre au serveur d'accepter une requête d'un autre processus (par exemple d'un automate se déclenchant à dates fixes) sans que la connexion avec le client ne reste active pendant le déroulement du traitement. L'entité retournée par la réponse rendra compte de la requête, et devra fournir un pointeur sur un composant d'information (état courant du traitement), ou donner une estimation de la date de conclusion probable définitive.

204 Pas de contenu

La requête a abouti et le serveur n'a rien à envoyer en retour.

Un utilisateur recevant ce message n'aura pas à rafraîchir son affichage, et maintiendra celui qui aura conduit à l'émission de la requête. Cette réponse a été instaurée pour permettre à un utilisateur de dérouler des scripts ou autres actions sans modifier l'affichage en cours. La réponse peut cependant contenir des métainformations dans des champs d'en-tête, concernant le document affiché dans la fenêtre active de l'utilisateur.

9.3 Redirection 3xx

Cette classe de messages précise que le client doit provoquer une action complémentaire pour que la requête puisse être conduite jusqu'à sa résolution finale. L'action peut être déclenchée par l'utilisateur final si et seulement si la méthode invoquée était GET ou HEAD. Un client ne peut automatiquement rediriger une requête plus de 5 fois. Il est supposé, si cela arrive, que la redirection s'effectue selon une boucle infinie.

300 Choix multiples

Ce code n'est pas utilisé directement par les applications HTTP/1.0 mais est défini pour servir de réponse par défaut à des codes 3xx non reconnus.

Il signifie en principe que la ressource visée est disponible en un ou plusieurs autres points du réseau. Sauf dans le cas d'une requête de type HEAD, la réponse doit contenir une entité dans laquelle sont listées les caractéristiques et localisations de la ressource demandée, à charge de l'utilisateur de choisir laquelle est la plus appropriée. Si le serveur affiche une préférence de choix, il doit en inscrire l'URL dans un champ Location; Certains clients utiliseront ce champ pour activer une redirection automatique.

301 Changement d'adresse définitive

La ressource demandée est désormais accessible via une autre URL, toute nouvelle requête lui étant appliquée devant utiliser cette nouvelle URL. Les clients implémentant une fonction de redirection automatique l'activeront et réémettront une requête avec l'URI correcte, lorsque c'est possible.

La nouvelle URL sera indiquée dans le champ d'en-tête Location de la réponse. Sauf dans le cas d'une requête de type HEAD, le corps d'entité de la réponse contiendra une note succincte avec un hyperlien vers la nouvelle URL.

Si le code d'état 301 est reçu en réponse à une requête POST, le client ne pourra rediriger automatiquement la requête sans en avoir demandé confirmation à l'utilisateur. En effet, il n'est pas dit que les conditions ayant été à l'origine de la requête n'aient pas changé.

Note: Certains clients, lorsqu'ils redirigent une requête POST, transforment par erreur cette requête en une requête GET après réception d'un code 301.

302 Changement d'adresse temporaire

La ressource demandée est actuellement et temporairement accessible via une autre URL. La redirection n'étant pas définitive, le client continuera d'utiliser l'URI-visée originale.

La nouvelle URL temporaire doit être spécifiée en réponse dans un champ Location. Sauf dans le cas d'une requête de type HEAD, le corps d'entité de la réponse contiendra une note succincte avec un hyperlien vers la nouvelle URI.

Si le code d'état 302 est reçu en réponse à une requête POST, le client ne pourra rediriger automatiquement la requête sans en avoir demandé confirmation à l'utilisateur. En effet, il n'est pas dit que les conditions ayant été à l'origine de la requête n'aient pas changé.

Note: Certains clients, lorsqu'ils redirigent une requête POST, transforment par erreur cette requête en une requête GET après réception d'un code 302.

304 Non modifié

Ce message est émis en retour d'une requête GET conditionnelle, lorsque l'accès à la ressource est permis, mais que celle-ci n'a pas été modifiée depuis la date et l'heure précisée dans le champ If-Modified-Since de la requête. Le serveur n'émet aucune entité liée à ce message. L'en-tête contiendra des informations à destination du gestionnaire de cache, ou ayant été modifiées sans que cela n'intervienne sur la date de dernière modification de la ressource elle-même. On y trouvera par exemple les champs: Date, Server, et Expires. Un système de cache recevant ce message devra remettre à jour les entités qu'il gère.

9.4 Erreur client 4xx

La classe 4xx de codes d'état est définie pour répondre au cas où il semble que le client ait commis une erreur. Si le client n'a pas encore achevé la transmission de sa requête lorsqu'il reçoit le code 4xx, alors il doit cesser toute transmission. Excepté lorsque ce code répond à une requête de type HEAD, le serveur pourra y inclure une entité explicitant la nature de l'erreur, et indiquant s'il s'agit d'une condition d'erreur temporaire ou permanente. Ces codes sont valides pour tous les types de requête.

Note: Si le client émet des données, les implémentations de TCP devront s'assurer que le client a bien émis tous les accusés de réception des paquets transportant la réponse avant de couper la connexion d'entrée. Si le client continue d'envoyer des données alors que le serveur a fermé la liaison, le TCP serveur émettra en retour un paquet RST (reset), qui risque de stimuler un effacement prématuré de toutes les données reçues dans les tampons interne du TCP client (y compris les données concernant la réponse) avant que celles-ci n'aient pu être transmises à l'application HTTP.

400 Requête incorrecte

La requête n'a pu être reconnue par le serveur pour cause d'une syntaxe incorrecte.

Le client n'est pas sensé émettre de nouveau cette requête sans l'avoir corrigée au préalable.

401 Non autorisé

La requête demandée nécessite une authentification de la part de l'utilisateur. La réponse doit inclure un champ d'en-tête WWW-Authenticate (Section 10.16) indiquant la demande d'authentification de la ressource. Le client est sensé répéter la demande en spécifiant un champ d'en-tête d'authentification correct (Section 10.2). Si la requête comportait déjà des données d'authentification, la réponse 401 indique les droits sont actuellement insuffisants pour cette authentification. Si la réponse 401 contient la même demande que la réponse précédente, et l'utilisateur a déjà suivi le processus d'identification au moins une fois, l'entité présentée dans la réponse doit être présentée à l'utilisateur, dans la mesure où les informations qu'elle contient peuvent être de nature à expliquer la faute. L'authentification des accès HTTP est décrite en détail en Section 11.

403 Interdit

Le serveur a compris la requête, mais refuse de la satisfaire.

Une démarche d'authentification n'y fera rien et cette requête ne doit pas être renouvelée. Si la méthode invoquée est différente de HEAD et le serveur souhaite rendre public la raison pour laquelle il refuse le traitement, il le fera dans l'entité liée à cette réponse. Ce code d'état est souvent utilisé lorsque le serveur ne souhaite pas s'étendre sur les raisons pour lesquelles il refuse un accès, ou parce que c'est la seule réponse qui convienne.

404 Non trouvé

Le serveur n'a trouvé aucune ressource correspondant à l'URI-visée. Aucune indication n'est donnée pour savoir si l'erreur est temporaire ou permanente. Si le serveur ne désire pas donner les raisons de l'échec dans ce cas, il peut utiliser le message de code 403 à la place de celui-ci.

9.5 Erreur serveur 5xx

Les réponses de code d'état débutant par un "5" indiquent une situation dans laquelle le serveur sait qu'il est la cause de l'erreur, ou est incapable de fournir le service demandé, bien que la requête ait été correctement formulée. Si le client reçoit cette réponse alors qu'il n'a pas encore terminé d'envoyer des données, il doit cesser immédiatement toute émission vers le serveur. Excepté lorsque la requête invoquée est de type HEAD, le serveur peut inclure une entité décrivant les causes de l'erreur, et s'il s'agit d'une condition permanente ou temporaire. Ces réponses s'appliquent quelque soit la requête, et ne nécessitent pas de champs d'en-tête particuliers.

500 Erreur serveur interne

Le serveur a été en présence d'un événement inattendu, qui l'a empêché de traiter la requête correctement.

501 Non implémenté

Le serveur ne supporte pas les fonctionnalités requises pour satisfaire la requête. Ceci est typique du cas où malgré une syntaxe conforme, le serveur ne reconnaît pas la méthode invoquée, et ne peut l'appliquer sur aucune ressource.

502 Erreur de routeur

Ce serveur, agissant en tant que proxy ou routeur, a reçu une réponse invalide de la part du serveur amont contacté pour satisfaire la requête.

503 Service indisponible

Les serveur ne peut momentanément traiter la requête, pour cause de surcharge ou de maintenance. Ceci implique une condition de faute temporaire, qui peut disparaître après un certain laps de temps .

Note: L'existence de ce code d'état 503 n'implique pas que le serveur l'utilise dès qu'il est surchargé. Certains serveurs dans cette situation refuseront tout bonnement la connexion.