10. Status Code Definitions (Définitions des Codes de Statut)
Chaque code de statut est décrit ci-dessous, y compris une description des méthodes qu'il peut suivre et toute méta-information requise dans la réponse.
10.1 Informational 1xx (Informatif)
Cette classe de code de statut indique une réponse provisoire, composée uniquement de la Status-Line et d'en-têtes optionnels, et se termine par une ligne vide. Il n'y a pas d'en-têtes requis pour cette classe de code de statut. Puisque HTTP/1.0 n'a défini aucun code de statut 1xx, les serveurs ne doivent pas (MUST NOT) envoyer une réponse 1xx à un client HTTP/1.0, sauf dans des conditions expérimentales.
Un client doit (MUST) être préparé à accepter une ou plusieurs réponses de statut 1xx avant la réponse régulière, même si le client n'attend pas de message de statut 100 (Continue). Les agents utilisateurs peuvent (MAY) ignorer les réponses de statut 1xx inattendues.
Un proxy doit (MUST) transmettre les réponses 1xx, à moins que la connexion entre le proxy et son client ait été fermée, ou à moins que le proxy lui-même ait demandé la génération de la réponse 1xx. (Par exemple, si un proxy ajoute un champ "Expect: 100-continue" lors de la transmission d'une requête, il n'a pas besoin de transmettre la réponse 100 (Continue) correspondante.)
10.1.1 100 Continue
Le client devrait (SHOULD) continuer avec sa requête. Cette réponse provisoire est utilisée pour informer le client que la partie initiale de la requête a été reçue et n'a pas encore été rejetée par le serveur. Le client devrait (SHOULD) continuer en envoyant le reste de la requête ou, si la requête est déjà terminée, ignorer cette réponse. Le serveur doit (MUST) envoyer une réponse finale après la fin de la requête. Voir la section 8.2.3 pour une discussion détaillée sur l'utilisation et la gestion de ce code de statut.
10.1.2 101 Switching Protocols (Changement de Protocoles)
Le serveur comprend et accepte de se conformer à la requête du client, via le champ d'en-tête Upgrade (section 14.42), pour un changement du protocole d'application utilisé sur cette connexion. Le serveur basculera vers les protocoles définis dans le champ d'en-tête Upgrade de la réponse immédiatement après la ligne vide qui termine la réponse 101.
Le protocole ne devrait (SHOULD) être changé que lorsque c'est avantageux de le faire. Par exemple, passer à une version plus récente de HTTP est avantageux par rapport aux versions plus anciennes, et passer à un protocole en temps réel et synchrone peut être avantageux lors de la livraison de ressources qui utilisent de telles fonctionnalités.
10.2 Successful 2xx (Succès)
Cette classe de code de statut indique que la requête du client a été reçue, comprise et acceptée avec succès.
10.2.1 200 OK
La requête a réussi. Les informations renvoyées avec la réponse dépendent de la méthode utilisée dans la requête, par exemple:
- GET - une entité correspondant à la ressource demandée est envoyée dans la réponse;
- HEAD - les champs d'en-tête d'entité correspondant à la ressource demandée sont envoyés dans la réponse sans corps de message;
- POST - une entité décrivant ou contenant le résultat de l'action;
- TRACE - une entité contenant le message de requête tel que reçu par le serveur final.
10.2.2 201 Created (Créé)
La requête a été satisfaite et a abouti à la création d'une nouvelle ressource. La ressource nouvellement créée peut être référencée par le(s) URI retourné(s) dans l'entité de la réponse, l'URI le plus spécifique de la ressource étant donné par un champ d'en-tête Location. La réponse devrait (SHOULD) inclure une entité contenant une liste des caractéristiques et de l'emplacement de la ressource à partir de laquelle l'utilisateur ou l'agent utilisateur peut choisir le plus approprié. Le format de l'entité est spécifié par le type de média donné dans le champ d'en-tête Content-Type. Le serveur d'origine doit (MUST) créer la ressource avant de retourner le code de statut 201. Si l'action ne peut pas être réalisée immédiatement, le serveur devrait (SHOULD) répondre avec la réponse 202 (Accepted) à la place.
Une réponse 201 peut (MAY) contenir un champ d'en-tête ETag indiquant la valeur actuelle de la balise d'entité pour la variante de requête qui vient d'être créée, voir section 14.19.
10.2.3 202 Accepted (Accepté)
La requête a été acceptée pour traitement, mais le traitement n'a pas été achevé. La requête pourrait ou non être finalement exécutée, car elle pourrait être interdite lorsque le traitement se produit réellement. Il n'y a pas de possibilité de renvoyer un code de statut à partir d'une telle opération asynchrone.
La réponse 202 est intentionnellement non engageante. Son but est de permettre à un serveur d'accepter une requête pour un autre processus (peut-être un processus orienté batch qui ne s'exécute qu'une fois par jour) sans exiger que la connexion de l'agent utilisateur au serveur persiste jusqu'à ce que le processus soit terminé. L'entité renvoyée avec cette réponse devrait (SHOULD) inclure une indication de l'état actuel de la requête et soit un pointeur vers un moniteur d'état ou une estimation du moment où l'utilisateur peut s'attendre à ce que la requête soit satisfaite.
10.2.4 203 Non-Authoritative Information (Informations Non Autoritatives)
Les méta-informations renvoyées dans l'en-tête d'entité ne proviennent pas du serveur d'origine, mais sont collectées à partir d'une copie locale ou tierce. L'ensemble présenté peut (MAY) être un sous-ensemble ou un sur-ensemble de la version originale. Par exemple, inclure des informations d'annotation locales sur la ressource pourrait résulter en un sur-ensemble des méta-informations connues du serveur d'origine. L'utilisation de ce code de réponse n'est pas requise et n'est appropriée que lorsque la réponse serait autrement 200 (OK).
10.2.5 204 No Content (Pas de Contenu)
Le serveur a satisfait la requête mais n'a pas besoin de renvoyer un corps d'entité, et pourrait vouloir renvoyer des méta-informations mises à jour. La réponse peut (MAY) inclure de nouvelles ou des méta-informations mises à jour sous la forme d'en-têtes d'entité, qui, si présents, devraient (SHOULD) être associés à la variante demandée.
Si le client est un agent utilisateur, il ne devrait pas (SHOULD NOT) changer sa vue de document à partir de celle qui a causé l'envoi de la requête. Cette réponse est principalement destinée à permettre que l'entrée pour l'action se produise sans causer de changement dans la vue de document active de l'agent utilisateur, bien que toute nouvelle ou mise à jour méta-information devrait (SHOULD) être appliquée au document actuellement dans la vue active de l'agent utilisateur.
La réponse 204 ne doit pas (MUST NOT) inclure un corps de message, et est donc toujours terminée par la première ligne vide après les champs d'en-tête.
10.2.6 205 Reset Content (Réinitialiser le Contenu)
Le serveur a satisfait la requête et l'agent utilisateur devrait (SHOULD) réinitialiser la vue de document qui a causé l'envoi de la requête. Cette réponse est principalement destinée à permettre l'entrée pour l'action d'entrée utilisateur, suivie d'un effacement du formulaire dans lequel l'entrée est donnée afin que l'utilisateur puisse facilement initier une autre action d'entrée. La réponse ne doit pas (MUST NOT) inclure d'entité.
10.2.7 206 Partial Content (Contenu Partiel)
Le serveur a satisfait la requête GET partielle pour la ressource. La requête doit (MUST) avoir inclus un champ d'en-tête Range (section 14.35) indiquant la plage désirée, et peut (MAY) avoir inclus un champ d'en-tête If-Range (section 14.27) pour rendre la requête conditionnelle.
La réponse doit (MUST) inclure les champs d'en-tête suivants:
-
Soit un champ d'en-tête Content-Range (section 14.16) indiquant la plage incluse dans cette réponse, soit un Content-Type multipart/byteranges incluant des champs Content-Range pour chaque partie. Si un champ d'en-tête Content-Length est présent dans la réponse, sa valeur doit (MUST) correspondre au nombre réel d'octets transmis dans le corps du message.
-
Date
-
ETag et/ou Content-Location, si l'en-tête aurait été envoyé dans une réponse 200 à la même requête
-
Expires, Cache-Control, et/ou Vary, si la valeur du champ pourrait différer de celle envoyée dans toute réponse précédente pour la même variante
Si la réponse 206 est le résultat d'une requête conditionnelle utilisant un validateur de cache fort (voir section 13.3.3), la réponse ne devrait pas (SHOULD NOT) inclure d'autres en-têtes d'entité. Cela empêche les incohérences entre les corps d'entité mis en cache et les en-têtes mis à jour. Sinon, la réponse doit (MUST) inclure tous les en-têtes d'entité qui auraient été renvoyés avec une réponse 200 (OK) à la même requête.
Un cache ne doit pas (MUST NOT) combiner une réponse 206 avec d'autres contenus précédemment mis en cache si l'ETag ou les en-têtes Last-Modified ne correspondent pas exactement à ceux reçus précédemment du serveur d'origine, et doit (MUST) traiter la réponse partielle comme complète.
Un cache qui ne prend pas en charge les en-têtes Range et Content-Range ne doit pas (MUST NOT) mettre en cache les réponses 206 (Partial).
10.3 Redirection 3xx (Redirection)
Cette classe de code de statut indique que des actions supplémentaires doivent être prises par l'agent utilisateur pour satisfaire la requête. L'action requise peut (MAY) être effectuée par l'agent utilisateur sans interaction avec l'utilisateur si et seulement si la méthode utilisée dans la deuxième requête est GET ou HEAD. Un client devrait (SHOULD) détecter les boucles de redirection infinies, car de telles boucles génèrent du trafic réseau pour chaque redirection.
Note: Les versions précédentes de cette spécification recommandaient un maximum de cinq redirections. Les développeurs de contenu devraient être conscients qu'il pourrait y avoir des clients qui n'obéissent pas à cette recommandation.
10.3.1 300 Multiple Choices (Choix Multiples)
La ressource demandée correspond à l'un d'un ensemble de représentations, chacune avec son propre emplacement spécifique, et des informations de négociation dirigée par l'agent (section 12) sont fournies afin que l'utilisateur (ou l'agent utilisateur) puisse sélectionner une représentation préférée et rediriger sa requête vers cet emplacement.
À moins que ce ne soit une requête HEAD, la réponse devrait (SHOULD) inclure une entité contenant une liste des caractéristiques et emplacements des ressources à partir desquels l'utilisateur ou l'agent utilisateur peut choisir le plus approprié. Le format de l'entité est spécifié par le type de média donné dans le champ d'en-tête Content-Type. En fonction du format et des capacités de l'agent utilisateur, la sélection de la plus appropriée peut être effectuée automatiquement. Cependant, cette spécification ne définit aucun standard pour une telle sélection automatique.
Si le serveur a une préférence de choix de représentation, il devrait (SHOULD) inclure l'URI spécifique pour cette représentation dans le champ Location; les agents utilisateurs peuvent (MAY) utiliser la valeur du champ Location pour la redirection automatique. Cette réponse est cachable sauf indication contraire.
10.3.2 301 Moved Permanently (Déplacé Définitivement)
La ressource demandée a reçu un nouvel URI permanent, et toute référence future à cette ressource devrait (SHOULD) utiliser l'un des URI retournés. Les clients avec des capacités d'édition de liens devraient (SHOULD) automatiquement re-lier les références au Request-URI vers une ou plusieurs des nouvelles références renvoyées par le serveur, lorsque cela est possible. Cette réponse est cachable sauf indication contraire.
Le nouvel URI permanent devrait (SHOULD) être donné par le champ Location dans la réponse. À moins que la méthode de requête ne soit HEAD, l'entité de la réponse devrait (SHOULD) contenir un hyperlien court vers le nouvel URI avec une brève note.
Si le code de statut 301 est reçu en réponse à une requête autre que GET ou HEAD, l'agent utilisateur ne doit pas (MUST NOT) rediriger automatiquement la requête à moins qu'elle ne puisse être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la requête a été émise.
Note: Lors de la redirection automatique d'une requête POST, certains agents utilisateurs HTTP/1.0 existants la modifient incorrectement en requête GET.
10.3.3 302 Found
La ressource demandée réside temporairement sous un URI différent. Puisque la redirection pourrait être modifiée de temps en temps, le client devrait (SHOULD) continuer à utiliser le Request-URI pour les requêtes futures. Cette réponse n'est cachable que si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
L'URI temporaire devrait (SHOULD) être donné par le champ Location dans la réponse. À moins que la méthode de requête ne soit HEAD, l'entité de la réponse devrait (SHOULD) contenir un hyperlien court vers le nouvel URI avec une brève note.
Si le code de statut 302 est reçu en réponse à une requête autre que GET ou HEAD, l'agent utilisateur ne doit pas (MUST NOT) rediriger automatiquement la requête à moins qu'elle ne puisse être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la requête a été émise.
Note: RFC 1945 et RFC 2068 spécifient que le client n'est pas autorisé à changer la méthode sur la requête redirigée. Cependant, la plupart des implémentations d'agents utilisateurs existantes traitent 302 comme s'il s'agissait d'une réponse 303, effectuant un GET sur la valeur du champ Location quelle que soit la méthode de requête d'origine. Les codes de statut 303 et 307 ont été ajoutés pour les serveurs qui souhaitent indiquer clairement quelle réaction est attendue du client.
10.3.4 303 See Other (Voir Autre)
La réponse à la requête peut être trouvée sous un URI différent et devrait (SHOULD) être récupérée en utilisant une méthode GET sur cette ressource. Cette méthode existe principalement pour permettre à la sortie d'une action activée par POST de rediriger l'agent utilisateur vers une ressource sélectionnée. Le nouvel URI n'est pas une référence de substitution pour la ressource demandée à l'origine. La réponse 303 ne doit pas (MUST NOT) être mise en cache, mais la réponse à la deuxième requête (redirigée) pourrait être cachable.
L'URI différent devrait être donné par le champ Location dans la réponse. À moins que la méthode de requête ne soit HEAD, l'entité de la réponse devrait (SHOULD) contenir un hyperlien court vers le nouvel URI avec une brève note.
Note: De nombreux agents utilisateurs pré-HTTP/1.1 ne comprennent pas le statut 303. Lorsque l'interopérabilité avec de tels clients est un problème, le code de statut 302 peut être utilisé à la place, car la plupart des agents utilisateurs réagissent à une réponse 302 comme l'exige une réponse 303.
10.3.5 304 Not Modified (Non Modifié)
Si le client a effectué une requête GET conditionnelle et l'accès est autorisé, mais le document n'a pas été modifié, le serveur devrait (SHOULD) répondre avec ce code de statut. La réponse 304 ne doit pas (MUST NOT) contenir de corps de message, et est donc toujours terminée par la première ligne vide après les champs d'en-tête.
La réponse doit (MUST) inclure les champs d'en-tête suivants:
- Date, sauf si son omission est requise par les règles de la section 14.18.1
Si un serveur d'origine sans horloge obéit à ces règles, et que les proxies et clients ajoutent leurs propres Date à tout en-tête Date qu'ils reçoivent, les caches fonctionneront correctement.
- ETag et/ou Content-Location, si l'en-tête aurait été envoyé dans une réponse 200 à la même requête
- Expires, Cache-Control, et/ou Vary, si la valeur du champ pourrait différer de celle envoyée dans toute réponse précédente pour la même variante
Si le GET conditionnel a utilisé un validateur de cache fort (voir section 13.3.3), la réponse ne devrait pas (SHOULD NOT) inclure d'autres en-têtes d'entité. Sinon (c'est-à-dire que le GET conditionnel a utilisé un validateur faible), la réponse ne doit pas (MUST NOT) inclure d'autres en-têtes d'entité; cela empêche les incohérences entre les corps d'entité mis en cache et les en-têtes mis à jour.
Si une réponse 304 indique une entité qui n'est pas actuellement mise en cache, alors le cache doit (MUST) ignorer la réponse et répéter la requête sans la condition.
Si un cache reçoit une réponse 304 qui met à jour une entrée de cache qu'il a actuellement mise en cache, le cache doit (MUST) mettre à jour l'entrée pour refléter toute nouvelle valeur de champ donnée dans la réponse.
10.3.6 305 Use Proxy (Utiliser un Proxy)
La ressource demandée doit (MUST) être accédée via le proxy donné par le champ Location. Le champ Location donne l'URI du proxy. Le destinataire est censé répéter cette requête unique via le proxy. Les réponses 305 doivent (MUST) être générées uniquement par les serveurs d'origine.
Note: RFC 2068 ne précisait pas clairement que 305 était destiné à rediriger une seule requête vers un proxy. Le fait de mettre en cache de manière inappropriée des réponses 305 a entraîné des problèmes de sécurité importants en dirigeant les requêtes suivantes vers ce proxy.
10.3.7 306 (Unused) (Non Utilisé)
Le code de statut 306 était utilisé dans une version précédente de la spécification, n'est plus utilisé, et le code est réservé.
10.3.8 307 Temporary Redirect (Redirection Temporaire)
La ressource demandée réside temporairement sous un URI différent. Puisque la redirection pourrait être modifiée de temps en temps, le client devrait (SHOULD) continuer à utiliser le Request-URI pour les requêtes futures. Cette réponse n'est cachable que si elle est indiquée par un champ d'en-tête Cache-Control ou Expires.
L'URI temporaire devrait (SHOULD) être donné par le champ Location dans la réponse. À moins que la méthode de requête ne soit HEAD, l'entité de la réponse devrait (SHOULD) contenir un hyperlien court vers le nouvel URI avec une brève note, car de nombreux agents utilisateurs pré-HTTP/1.1 ne comprennent pas le statut 307. Par conséquent, la note devrait (SHOULD) contenir les informations nécessaires à l'utilisateur pour répéter la requête originale sur le nouvel URI.
Si le code de statut 307 est reçu en réponse à une requête autre que GET ou HEAD, l'agent utilisateur ne doit pas (MUST NOT) rediriger automatiquement la requête à moins qu'elle ne puisse être confirmée par l'utilisateur, car cela pourrait changer les conditions dans lesquelles la requête a été émise.
10.4 Client Error 4xx (Erreur Client)
La classe de code de statut 4xx est destinée aux cas où le client semble avoir commis une erreur. Sauf lors de la réponse à une requête HEAD, le serveur devrait (SHOULD) inclure une entité contenant une explication de la situation d'erreur, et si c'est une condition temporaire ou permanente. Ces codes de statut sont applicables à toute méthode de requête. Les agents utilisateurs devraient (SHOULD) afficher toute entité incluse à l'utilisateur.
Si le client envoie des données, une implémentation de serveur utilisant TCP devrait (SHOULD) faire attention à s'assurer que le client reconnaît la réception des paquets contenant la réponse, avant que le serveur ne ferme la connexion d'entrée. Si le client continue à envoyer des données au serveur après la fermeture, la pile TCP du serveur enverra un paquet de réinitialisation au client, ce qui peut effacer les tampons d'entrée non reconnus du client avant que l'application HTTP ne puisse les lire et les interpréter.
10.4.1 400 Bad Request (Mauvaise Requête)
La requête n'a pas pu être comprise par le serveur en raison d'une syntaxe mal formée. Le client ne devrait pas (SHOULD NOT) répéter la requête sans modifications.
10.4.2 401 Unauthorized (Non Autorisé)
La requête nécessite une authentification utilisateur. La réponse doit (MUST) inclure un champ d'en-tête WWW-Authenticate (section 14.47) contenant un défi applicable à la ressource demandée. Le client peut (MAY) répéter la requête avec un champ d'en-tête Authorization approprié (section 14.8). Si la requête incluait déjà des informations d'identification Authorization, alors la réponse 401 indique que l'autorisation a été refusée pour ces informations d'identification. Si la réponse 401 contient le même défi qu'une réponse précédente, et que l'agent utilisateur a déjà essayé l'authentification au moins une fois, alors l'entité donnée dans la réponse devrait (SHOULD) être présentée à l'utilisateur, car cette entité pourrait inclure des informations de diagnostic pertinentes. L'authentification d'accès HTTP est expliquée dans "HTTP Authentication: Basic and Digest Access Authentication" [43].
10.4.3 402 Payment Required (Paiement Requis)
Ce code est réservé pour un usage futur.
10.4.4 403 Forbidden (Interdit)
Le serveur a compris la requête, mais refuse de la satisfaire. L'autorisation n'aidera pas et la requête ne devrait pas (SHOULD NOT) être répétée. Si la méthode de requête n'était pas HEAD et que le serveur souhaite rendre public pourquoi la requête n'a pas été satisfaite, il devrait (SHOULD) décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas rendre cette information disponible au client, le code de statut 404 (Not Found) peut être utilisé à la place.
10.4.5 404 Not Found (Non Trouvé)
Le serveur n'a rien trouvé correspondant au Request-URI. Aucune indication n'est donnée si la condition est temporaire ou permanente. Le code de statut 410 (Gone) devrait (SHOULD) être utilisé si le serveur sait, via un mécanisme configurable en interne, qu'une ancienne ressource est définitivement indisponible et n'a pas d'adresse de redirection. Ce code de statut est couramment utilisé lorsque le serveur ne souhaite pas révéler exactement pourquoi la requête a été refusée, ou lorsqu'aucune autre réponse n'est applicable.
10.4.6 405 Method Not Allowed (Méthode Non Autorisée)
La méthode spécifiée dans la Request-Line n'est pas autorisée pour la ressource identifiée par le Request-URI. La réponse doit (MUST) inclure un en-tête Allow contenant une liste de méthodes valides pour la ressource demandée.
10.4.7 406 Not Acceptable (Non Acceptable)
La ressource identifiée par la requête n'est capable de générer que des entités de réponse dont les caractéristiques de contenu ne sont pas acceptables selon les en-têtes accept envoyés dans la requête.
À moins que ce ne soit une requête HEAD, la réponse devrait (SHOULD) inclure une entité contenant une liste des caractéristiques et emplacements des entités disponibles à partir desquels l'utilisateur ou l'agent utilisateur peut choisir le plus approprié. Le format de l'entité est spécifié par le type de média donné dans le champ d'en-tête Content-Type. En fonction du format et des capacités de l'agent utilisateur, la sélection de la plus appropriée peut être effectuée automatiquement. Cependant, cette spécification ne définit aucun standard pour une telle sélection automatique.
Note: Les serveurs HTTP/1.1 sont autorisés à retourner des réponses qui ne sont pas acceptables selon les en-têtes accept envoyés dans la requête. Dans certains cas, cela peut même être préférable à l'envoi d'une réponse 406. Les agents utilisateurs sont encouragés à inspecter les en-têtes d'une réponse entrante pour déterminer si elle est acceptable.
Si la réponse pourrait être inacceptable, un agent utilisateur devrait (SHOULD) temporairement arrêter de recevoir plus de données et consulter l'utilisateur pour une décision sur l'action ultérieure.
10.4.8 407 Proxy Authentication Required (Authentification Proxy Requise)
Ce code est similaire à 401 (Unauthorized), mais indique que le client doit d'abord s'authentifier auprès du proxy. Le proxy doit (MUST) retourner un champ d'en-tête Proxy-Authenticate (section 14.33) contenant un défi applicable au proxy pour la ressource demandée. Le client peut (MAY) répéter la requête avec un champ d'en-tête Proxy-Authorization approprié (section 14.34). L'authentification d'accès HTTP est expliquée dans "HTTP Authentication: Basic and Digest Access Authentication" [43].
10.4.9 408 Request Timeout (Délai d'Attente de la Requête)
Le client n'a pas produit de requête dans le délai que le serveur était prêt à attendre. Le client peut (MAY) répéter la requête sans modifications à tout moment ultérieur.
10.4.10 409 Conflict (Conflit)
La requête n'a pas pu être complétée en raison d'un conflit avec l'état actuel de la ressource. Ce code n'est autorisé que dans des situations où l'on s'attend à ce que l'utilisateur puisse résoudre le conflit et soumettre à nouveau la requête. Le corps de la réponse devrait (SHOULD) inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. Idéalement, l'entité de réponse inclurait suffisamment d'informations pour que l'utilisateur ou l'agent utilisateur résolve le problème; cependant, cela peut ne pas être possible et n'est pas requis.
Les conflits sont le plus susceptibles de se produire en réponse à une requête PUT. Par exemple, si le versioning était utilisé et que l'entité mise avec PUT incluait des changements à une ressource qui entrent en conflit avec ceux faits par une requête (tierce) antérieure, le serveur pourrait utiliser une réponse 409 pour indiquer qu'il ne peut pas compléter la requête. Dans ce cas, l'entité de réponse contiendrait probablement une liste des différences entre les deux versions dans un format défini par le Content-Type de la réponse.
10.4.11 410 Gone (Disparu)
La ressource demandée n'est plus disponible sur le serveur et aucune adresse de redirection n'est connue. Cette condition est considérée comme permanente. Les clients avec des capacités d'édition de liens devraient (SHOULD) supprimer les références au Request-URI après approbation de l'utilisateur. Si le serveur ne sait pas, ou n'a pas de moyen de déterminer, si la condition est permanente, le code de statut 404 (Not Found) devrait (SHOULD) être utilisé à la place. Cette réponse est cachable sauf indication contraire.
La réponse 410 est principalement destinée à aider la tâche de maintenance Web en notifiant au destinataire que la ressource est intentionnellement indisponible et que les propriétaires du serveur souhaitent que les liens distants vers cette ressource soient supprimés. Un tel événement est courant pour les services promotionnels à durée limitée et pour les ressources appartenant à des individus qui ne travaillent plus sur le site du serveur d'origine. Il n'est pas nécessaire de marquer toutes les ressources définitivement indisponibles comme "gone" ou de conserver la marque pendant une durée quelconque - cela est laissé à la discrétion du propriétaire du serveur.
10.4.12 411 Length Required (Longueur Requise)
Le serveur refuse d'accepter la requête sans un Content-Length défini. Le client peut (MAY) répéter la requête s'il ajoute un champ d'en-tête Content-Length valide contenant la longueur du corps du message dans le message de requête.
10.4.13 412 Precondition Failed (Échec de la Précondition)
La précondition donnée dans un ou plusieurs des champs d'en-tête de la requête a été évaluée comme fausse lorsqu'elle a été testée sur le serveur. Ce code de statut permet au client de placer des préconditions sur les méta-informations de ressource actuelles (données de champ d'en-tête) et ainsi d'empêcher que la méthode de requête ne soit appliquée à une ressource autre que celle prévue.
10.4.14 413 Request Entity Too Large (Entité de Requête Trop Grande)
Le serveur refuse de traiter une requête car l'entité de requête est plus grande que le serveur est disposé ou capable de traiter. Le serveur peut (MAY) fermer la connexion pour empêcher le client de continuer la requête.
Si la condition est temporaire, le serveur devrait (SHOULD) inclure un champ d'en-tête Retry-After pour indiquer qu'elle est temporaire et après quel délai le client peut essayer à nouveau.
10.4.15 414 Request-URI Too Long (URI de Requête Trop Long)
Le serveur refuse de servir la requête car le Request-URI est plus long que le serveur est disposé à interpréter. Cette condition rare ne se produira que lorsque: un client a incorrectement converti une requête POST en requête GET avec de longues informations de requête, lorsque le client est descendu dans un "trou noir" de redirection (par exemple, un préfixe de redirection qui pointe vers un suffixe de lui-même), ou lorsque le serveur est attaqué par un client tentant d'exploiter des trous de sécurité présents dans certains serveurs utilisant des tampons de longueur fixe pour lire ou manipuler le Request-URI.
10.4.16 415 Unsupported Media Type (Type de Média Non Supporté)
Le serveur refuse de servir la requête car l'entité de la requête est dans un format non supporté par la ressource demandée pour la méthode demandée.
10.4.17 416 Requested Range Not Satisfiable (Plage Demandée Non Satisfaisable)
Un serveur devrait (SHOULD) retourner une réponse avec ce code de statut si une requête incluait un champ d'en-tête de requête Range (section 14.35), et aucune des valeurs de spécificateur de plage dans ce champ ne chevauche la plage actuelle de la ressource sélectionnée, et la requête n'incluait pas un champ d'en-tête de requête If-Range. (Pour les plages d'octets, cela signifie que la position du premier octet de toutes les valeurs de byte-range-spec était supérieure à la longueur actuelle de la ressource sélectionnée.)
Lorsque ce code de statut est retourné pour une plage d'octets, la réponse devrait (SHOULD) inclure un champ d'en-tête d'entité Content-Range spécifiant la longueur actuelle de la ressource sélectionnée (voir section 14.16). Cette réponse ne doit pas (MUST NOT) utiliser le content-type multipart/byteranges.
10.4.18 417 Expectation Failed (Échec de l'Attente)
L'attente donnée dans un champ d'en-tête de requête Expect (voir section 14.20) n'a pas pu être satisfaite par ce serveur, ou, si le serveur est un proxy, le serveur a des preuves sans ambiguïté que la requête ne peut pas être satisfaite par le serveur du saut suivant.
10.5 Server Error 5xx (Erreur Serveur)
Les codes de statut de réponse commençant par le chiffre "5" indiquent des cas où le serveur est conscient qu'il a commis une erreur ou est incapable d'exécuter la requête. Sauf lors de la réponse à une requête HEAD, le serveur devrait (SHOULD) inclure une entité contenant une explication de la situation d'erreur, et si c'est une condition temporaire ou permanente. Les agents utilisateurs devraient (SHOULD) afficher toute entité incluse à l'utilisateur. Ces codes de réponse sont applicables à toute méthode de requête.
10.5.1 500 Internal Server Error (Erreur Interne du Serveur)
Le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la requête.
10.5.2 501 Not Implemented (Non Implémenté)
Le serveur ne prend pas en charge la fonctionnalité requise pour satisfaire la requête. C'est la réponse appropriée lorsque le serveur ne reconnaît pas la méthode de requête et n'est pas capable de la prendre en charge pour aucune ressource.
10.5.3 502 Bad Gateway (Mauvaise Passerelle)
Le serveur, agissant en tant que passerelle ou proxy, a reçu une réponse invalide du serveur en amont qu'il a accédé en tentant de satisfaire la requête.
10.5.4 503 Service Unavailable (Service Indisponible)
Le serveur est actuellement incapable de traiter la requête en raison d'une surcharge temporaire ou d'une maintenance du serveur. Cela implique que c'est une condition temporaire qui sera soulagée après un certain délai. Si connu, la durée du délai peut (MAY) être indiquée dans un en-tête Retry-After. Si aucun Retry-After n'est donné, le client devrait (SHOULD) gérer la réponse comme il le ferait pour une réponse 500.
Note: L'existence du code de statut 503 n'implique pas qu'un serveur doit l'utiliser lors d'une surcharge. Certains serveurs peuvent simplement souhaiter refuser la connexion.
10.5.5 504 Gateway Timeout (Délai d'Attente de Passerelle)
Le serveur, agissant en tant que passerelle ou proxy, n'a pas reçu de réponse en temps opportun du serveur en amont qu'il devait accéder pour compléter la requête.
Note: Notez que 408 (Request Timeout) doit être distingué de ce code de statut.
10.5.6 505 HTTP Version Not Supported (Version HTTP Non Supportée)
Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version du protocole HTTP qui a été utilisée dans le message de requête. Le serveur indique qu'il est incapable ou ne veut pas compléter la requête en utilisant la même version majeure que le client, comme décrit dans la section 3.1, autre que d'utiliser ce message d'erreur. La réponse devrait (SHOULD) contenir une entité décrivant pourquoi cette version n'est pas prise en charge et quels autres protocoles sont pris en charge par ce serveur.