RFC: 1945
Statut : Information
Retour à l'index des normes : INDEX FRANCAIS
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.
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.
Cette classe précise que la requête du client a été correctement transmise, interprétée, et exécutée.
La requête a abouti. L'information retournée en réponse dépend de la requête émise, comme suit:
GET
HEAD
POST
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.
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.
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.
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.
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.
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é.
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é.
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.
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.
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.
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.
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.
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.
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.
Le serveur a été en présence d'un événement inattendu, qui l'a empêché de traiter la requête correctement.
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.
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.
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 .