6. Response Status Codes (Codes d'état de réponse)

L'élément status-code est un code entier à trois chiffres donnant le résultat de la tentative de comprendre et de satisfaire la requête.

Les codes d'état HTTP sont extensibles. Les clients HTTP ne sont pas tenus de comprendre la signification de tous les codes d'état enregistrés, bien qu'une telle compréhension soit évidemment souhaitable. Cependant, un client DOIT comprendre la classe de tout code d'état, comme indiqué par le premier chiffre, et traiter un code d'état non reconnu comme étant équivalent au code d'état x00 de cette classe, à l'exception qu'un destinataire NE DOIT PAS mettre en cache une réponse avec un code d'état non reconnu.

Par exemple, si un code d'état non reconnu de 471 est reçu par un client, le client peut supposer qu'il y avait quelque chose qui n'allait pas avec sa requête et traiter la réponse comme s'il avait reçu un code d'état 400 (Bad Request). Le message de réponse contiendra généralement une représentation qui explique l'état.

Le premier chiffre du code d'état définit la classe de réponse. Les deux derniers chiffres n'ont aucun rôle de catégorisation. Il existe cinq valeurs pour le premier chiffre :

• 1xx (Informational / Informationnel) : La requête a été reçue, traitement en cours
• 2xx (Successful / Réussi) : La requête a été reçue, comprise et acceptée avec succès
• 3xx (Redirection) : Une action supplémentaire doit être entreprise pour compléter la requête
• 4xx (Client Error / Erreur client) : La requête contient une syntaxe incorrecte ou ne peut pas être satisfaite
• 5xx (Server Error / Erreur serveur) : Le serveur n'a pas réussi à satisfaire une requête apparemment valide

6.1. Overview of Status Codes (Aperçu des codes d'état)

Les codes d'état listés ci-dessous sont définis dans cette spécification. Les phrases de raison listées ici ne sont que des recommandations -- elles peuvent être remplacées par des équivalents locaux sans affecter le protocole.

Les réponses avec des codes d'état définis comme pouvant être mis en cache par défaut (par exemple, 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, et 501 dans cette spécification) peuvent être réutilisées par un cache avec expiration heuristique sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites [RFC7234] ; tous les autres codes d'état ne sont pas mis en cache par défaut.

Code	Phrase de raison	Défini dans
100	Continue	Section 6.2.1
101	Switching Protocols	Section 6.2.2
200	OK	Section 6.3.1
201	Created	Section 6.3.2
202	Accepted	Section 6.3.3
203	Non-Authoritative Information	Section 6.3.4
204	No Content	Section 6.3.5
205	Reset Content	Section 6.3.6
206	Partial Content	RFC7233
300	Multiple Choices	Section 6.4.1
301	Moved Permanently	Section 6.4.2
302	Found	Section 6.4.3
303	See Other	Section 6.4.4
304	Not Modified	RFC7232
305	Use Proxy	Section 6.4.5
306	(Unused)	Section 6.4.6
307	Temporary Redirect	Section 6.4.7
400	Bad Request	Section 6.5.1
401	Unauthorized	RFC7235
402	Payment Required	Section 6.5.2
403	Forbidden	Section 6.5.3
404	Not Found	Section 6.5.4
405	Method Not Allowed	Section 6.5.5
406	Not Acceptable	Section 6.5.6
407	Proxy Authentication Required	RFC7235
408	Request Timeout	Section 6.5.7
409	Conflict	Section 6.5.8
410	Gone	Section 6.5.9
411	Length Required	Section 6.5.10
412	Precondition Failed	RFC7232
413	Payload Too Large	Section 6.5.11
414	URI Too Long	Section 6.5.12
415	Unsupported Media Type	Section 6.5.13
416	Range Not Satisfiable	RFC7233
417	Expectation Failed	Section 6.5.14
426	Upgrade Required	Section 6.5.15
500	Internal Server Error	Section 6.6.1
501	Not Implemented	Section 6.6.2
502	Bad Gateway	Section 6.6.3
503	Service Unavailable	Section 6.6.4
504	Gateway Timeout	Section 6.6.5
505	HTTP Version Not Supported	Section 6.6.6

6.2. Informational 1xx

La classe 1xx (Informational) de code d'état indique une réponse provisoire pour communiquer l'état de la connexion ou la progression de la requête avant de compléter l'action demandée et d'envoyer une réponse finale. Puisque HTTP/1.0 n'a défini aucun code d'état 1xx, un serveur NE DOIT PAS envoyer une réponse 1xx à un client HTTP/1.0.

Une réponse 1xx est terminée par la première ligne vide après la ligne d'état (la ligne vide signalant la fin de la section d'en-tête). Puisqu'une réponse 1xx ne peut pas contenir de corps de message, elle est toujours terminée par la première ligne vide après les champs d'en-tête.

Les clients HTTP/1.1 DOIVENT être préparés à recevoir une ou plusieurs réponses 1xx avant une réponse finale, même si le client ne s'attend pas à un message d'état 100 (Continue). Un agent utilisateur PEUT ignorer les réponses 1xx inattendues.

Un proxy DOIT transférer les réponses 1xx à moins que le proxy lui-même n'ait demandé la génération de la réponse 1xx. Par exemple, si un proxy ajoute un champ "Expect: 100-continue" lorsqu'il transmet une requête, il n'a pas besoin de transférer les réponses 100 (Continue) correspondantes.

6.2.1. 100 Continue

Le code d'état 100 (Continue) indique que la partie initiale d'une requête a été reçue et n'a pas encore été rejetée par le serveur. Le serveur a l'intention d'envoyer une réponse finale après que la requête ait été entièrement reçue et traitée.

Lorsque la requête contient un champ d'en-tête Expect qui inclut une attente 100-continue, la réponse 100 indique que le serveur souhaite recevoir le corps de la charge utile de la requête, comme décrit dans Section 5.1.1. Le client doit continuer à envoyer la requête et ignorer la réponse 100.

Si la requête ne contenait pas un champ d'en-tête Expect contenant l'attente 100-continue, le client peut simplement ignorer cette réponse provisoire.

6.2.2. 101 Switching Protocols

Le code d'état 101 (Switching Protocols) indique que le serveur comprend et est disposé à se conformer à la requête du client, via le champ d'en-tête Upgrade (Section 6.7 de [RFC7230]), pour un changement dans le protocole d'application utilisé sur cette connexion. Le serveur DOIT générer un champ d'en-tête Upgrade dans la réponse qui indique quel(s) protocole(s) sera(ont) en vigueur immédiatement après la ligne vide qui termine la réponse 101.

On suppose que le serveur n'acceptera de changer de protocoles que lorsque cela est avantageux de le faire. Par exemple, passer à une version plus récente de HTTP pourrait être avantageux par rapport aux anciennes versions, et passer à un protocole en temps réel synchrone pourrait être avantageux lors de la livraison de ressources qui utilisent de telles fonctionnalités.

6.3. Successful 2xx

La classe 2xx (Successful) de code d'état indique que la requête du client a été reçue, comprise et acceptée avec succès.

6.3.1. 200 OK

Le code d'état 200 (OK) indique que la requête a réussi. La charge utile envoyée dans une réponse 200 dépend de la méthode de requête. Pour les méthodes définies par cette spécification, la signification prévue de la charge utile peut être résumée comme suit :

• GET : une représentation de la ressource cible ;
• HEAD : la même représentation que GET, mais sans les données de représentation ;
• POST : une représentation de l'état de, ou des résultats obtenus à partir de, l'action ;
• PUT, DELETE : une représentation de l'état de l'action ;
• OPTIONS : une représentation des options de communication ;
• TRACE : une représentation du message de requête tel que reçu par le serveur final.

Hormis les réponses à CONNECT, une réponse 200 a toujours une charge utile, bien qu'un serveur d'origine PUISSE générer un corps de charge utile de longueur zéro. Si aucune charge utile n'est souhaitée, un serveur d'origine devrait envoyer 204 (No Content) à la place. Pour CONNECT, aucune charge utile n'est autorisée car le résultat réussi est un tunnel, qui commence immédiatement après la section d'en-tête de réponse 200.

Une réponse 200 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.3.2. 201 Created

Le code d'état 201 (Created) indique que la requête a été satisfaite et a abouti à la création d'une ou plusieurs nouvelles ressources. La ressource principale créée par la requête est identifiée soit par un champ d'en-tête Location dans la réponse, soit, si aucun champ Location n'est reçu, par l'URI de requête effective.

La charge utile de réponse 201 décrit et lie généralement à la(aux) ressource(s) créée(s). Voir Section 7.2 pour une discussion de la signification et du but des champs d'en-tête de validateur, tels que ETag et Last-Modified, dans une réponse 201.

6.3.3. 202 Accepted

Le code d'état 202 (Accepted) indique que la requête a été acceptée pour traitement, mais que le traitement n'est pas terminé. La requête pourrait ou non être finalement exécutée, car elle pourrait être interdite lorsque le traitement a effectivement lieu. Il n'y a pas de facilité dans HTTP pour renvoyer un code d'état d'une 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 n'est exécuté qu'une fois par jour) sans exiger que la connexion de l'agent utilisateur au serveur persiste jusqu'à ce que le processus soit terminé. La représentation envoyée avec cette réponse devrait décrire l'état actuel de la requête et pointer vers (ou intégrer) un moniteur d'état qui peut fournir à l'utilisateur une estimation de quand la requête sera satisfaite.

6.3.4. 203 Non-Authoritative Information

Le code d'état 203 (Non-Authoritative Information) indique que la requête a réussi mais que la charge utile incluse a été modifiée par rapport à celle de la réponse 200 (OK) du serveur d'origine par un proxy de transformation (Section 5.7.2 de [RFC7230]). Ce code d'état permet au proxy de notifier les destinataires lorsqu'une transformation a été appliquée, car cette connaissance pourrait avoir un impact sur les décisions ultérieures concernant le contenu. Par exemple, les futures requêtes de validation de cache pour le contenu pourraient ne s'appliquer que le long du même chemin de requête (à travers les mêmes proxys).

La réponse 203 est similaire au code Warning de 214 Transformation Applied (Section 5.5 de [RFC7234]), qui a l'avantage d'être applicable aux réponses avec n'importe quel code d'état.

Une réponse 203 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.3.5. 204 No Content

Le code d'état 204 (No Content) indique que le serveur a satisfait la requête avec succès et qu'il n'y a pas de contenu supplémentaire à envoyer dans le corps de charge utile de réponse. Les métadonnées dans les champs d'en-tête de réponse se réfèrent à la ressource cible et à sa représentation sélectionnée après l'application de l'action demandée.

Par exemple, si un code d'état 204 est reçu en réponse à une requête PUT et que la réponse contient un champ d'en-tête ETag, alors le PUT a réussi et le champ-valeur ETag contient l'entity-tag pour la nouvelle représentation de cette ressource cible.

La réponse 204 permet à un serveur d'indiquer que l'action a été appliquée avec succès à la ressource cible, tout en impliquant que l'agent utilisateur n'a pas besoin de s'éloigner de sa "vue de document" actuelle (le cas échéant). Le serveur suppose que l'agent utilisateur fournira une indication du succès à son utilisateur, conformément à sa propre interface, et appliquera toutes métadonnées nouvelles ou mises à jour dans la réponse à sa représentation active.

Par exemple, un code d'état 204 est couramment utilisé avec les interfaces d'édition de documents correspondant à une action "enregistrer", de sorte que le document en cours d'enregistrement reste disponible pour l'utilisateur pour l'édition. Il est également fréquemment utilisé avec des interfaces qui s'attendent à ce que les transferts de données automatisés soient répandus, comme dans les systèmes de contrôle de version distribués.

Une réponse 204 est terminée par la première ligne vide après les champs d'en-tête car elle ne peut pas contenir de corps de message.

Une réponse 204 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.3.6. 205 Reset Content

Le code d'état 205 (Reset Content) indique que le serveur a satisfait la requête et souhaite que l'agent utilisateur réinitialise la "vue de document", qui a causé l'envoi de la requête, à son état d'origine tel que reçu du serveur d'origine.

Cette réponse est destinée à prendre en charge un cas d'utilisation courant de saisie de données où l'utilisateur reçoit un contenu qui prend en charge la saisie de données (un formulaire, un bloc-notes, un canevas, etc.), saisit ou manipule des données dans cet espace, provoque la soumission des données saisies dans une requête, puis le mécanisme de saisie de données est réinitialisé pour la prochaine entrée afin que l'utilisateur puisse facilement initier une autre action d'entrée.

Puisque le code d'état 205 implique qu'aucun contenu supplémentaire ne sera fourni, un serveur NE DOIT PAS générer une charge utile dans une réponse 205. En d'autres termes, un serveur DOIT faire l'une des choses suivantes pour une réponse 205 : a) indiquer un corps de longueur zéro pour la réponse en incluant un champ d'en-tête Content-Length avec une valeur de 0 ; b) indiquer une charge utile de longueur zéro pour la réponse en incluant un champ d'en-tête Transfer-Encoding avec une valeur de chunked et un corps de message constitué d'un seul morceau de longueur zéro ; ou, c) fermer la connexion immédiatement après avoir envoyé la ligne vide terminant la section d'en-tête.

6.4. Redirection 3xx

La classe 3xx (Redirection) de code d'état indique qu'une action supplémentaire doit être entreprise par l'agent utilisateur afin de satisfaire la requête. Si un champ d'en-tête Location (Section 7.1.2) est fourni, l'agent utilisateur PEUT rediriger automatiquement sa requête vers l'URI référencé par la valeur du champ Location, même si le code d'état spécifique n'est pas compris. La redirection automatique doit être effectuée avec prudence pour les méthodes qui ne sont pas connues comme étant sûres, comme défini dans Section 4.2.1, car l'utilisateur pourrait ne pas souhaiter rediriger une requête non sûre.

Il existe plusieurs types de redirections :

1. Les redirections qui indiquent que la ressource pourrait être disponible à un URI différent, comme fourni par le champ Location, comme dans les codes d'état 301 (Moved Permanently), 302 (Found), et 307 (Temporary Redirect).

2. La redirection qui offre un choix de ressources correspondantes, chacune capable de représenter la cible de requête d'origine, comme dans le code d'état 300 (Multiple Choices).

3. La redirection vers une ressource différente, identifiée par le champ Location, qui peut représenter une réponse indirecte à la requête, comme dans le code d'état 303 (See Other).

4. La redirection vers un résultat précédemment mis en cache, comme dans le code d'état 304 (Not Modified).

Note : Dans HTTP/1.0, les codes d'état 301 (Moved Permanently) et 302 (Found) ont été définis pour le premier type de redirection ([RFC1945], Section 9.3). Les premiers agents utilisateurs se sont divisés sur la question de savoir si la méthode appliquée à la cible de redirection serait la même que la requête d'origine ou serait réécrite en GET. Bien que HTTP ait initialement défini les premières sémantiques pour 301 et 302 (pour correspondre à son implémentation d'origine au CERN), et défini 303 (See Other) pour correspondre aux dernières sémantiques, la pratique dominante a progressivement convergé vers les dernières sémantiques pour 301 et 302 également. La première révision de HTTP/1.1 a ajouté 307 (Temporary Redirect) pour indiquer les premières sémantiques sans être impacté par une pratique divergente. Plus de 10 ans plus tard, la plupart des agents utilisateurs réécrivent toujours la méthode pour 301 et 302 ; par conséquent, cette spécification rend ce comportement conforme lorsque la requête d'origine est POST.

Un client DEVRAIT détecter et intervenir dans les redirections cycliques (c'est-à-dire, les boucles de redirection "infinies").

Note : Une version antérieure de cette spécification recommandait un maximum de cinq redirections ([RFC2068], Section 10.3). Les développeurs de contenu doivent être conscients que certains clients pourraient mettre en œuvre une telle limitation fixe.

6.4.1. 300 Multiple Choices

Le code d'état 300 (Multiple Choices) indique que la ressource cible a plus d'une représentation, chacune avec son propre identifiant plus spécifique, et que des informations sur les alternatives sont fournies afin que l'utilisateur (ou l'agent utilisateur) puisse sélectionner une représentation préférée en redirigeant sa requête vers un ou plusieurs de ces identifiants. En d'autres termes, le serveur souhaite que l'agent utilisateur s'engage dans une négociation réactive pour sélectionner la(les) représentation(s) la(les) plus appropriée(s) pour ses besoins (Section 3.4.2).

Si le serveur a un choix préféré, le serveur DEVRAIT générer un champ d'en-tête Location contenant une référence URI du choix préféré. L'agent utilisateur PEUT utiliser la valeur du champ Location pour la redirection automatique.

Pour les méthodes de requête autres que HEAD, le serveur DEVRAIT générer une charge utile dans la réponse 300 contenant une liste de métadonnées de représentation et de référence(s) URI à partir desquelles l'utilisateur ou l'agent utilisateur peut choisir celui qui est le plus préféré. L'agent utilisateur PEUT faire une sélection à partir de cette liste automatiquement s'il comprend le type de média fourni. Un format spécifique pour la sélection automatique n'est pas défini par cette spécification car HTTP essaie de rester orthogonal à la définition de ses charges utiles. En pratique, la représentation est fournie dans un format facilement analysable censé être acceptable pour l'agent utilisateur, tel que déterminé par une conception partagée ou une négociation de contenu, ou dans un format hypertexte couramment accepté.

Une réponse 300 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

Note : La proposition originale pour le code d'état 300 définissait le champ d'en-tête URI comme fournissant une liste de représentations alternatives, de sorte qu'il serait utilisable pour les réponses 200, 300 et 406 et être transféré dans les réponses à la méthode HEAD. Cependant, le manque de déploiement et le désaccord sur la syntaxe ont conduit à la suppression d'URI et d'Alternates (une proposition ultérieure) de cette spécification. Il est possible de communiquer la liste en utilisant un ensemble de champs d'en-tête Link [RFC5988], chacun avec une relation de "alternate", bien que le déploiement soit un problème de poule et d'œuf.

6.4.2. 301 Moved Permanently

Le code d'état 301 (Moved Permanently) indique que la ressource cible s'est vu attribuer un nouvel URI permanent et que toutes les références futures à cette ressource devraient utiliser l'un des URI inclus. Les clients avec des capacités d'édition de liens devraient automatiquement relier les références à l'URI de requête effective à une ou plusieurs des nouvelles références envoyées par le serveur, lorsque cela est possible.

Le serveur DEVRAIT générer un champ d'en-tête Location dans la réponse contenant une référence URI préférée pour le nouvel URI permanent. L'agent utilisateur PEUT utiliser la valeur du champ Location pour la redirection automatique. La charge utile de réponse du serveur contient généralement une courte note hypertexte avec un hyperlien vers le(s) nouvel(aux) URI.

Note : Pour des raisons historiques, un agent utilisateur PEUT changer la méthode de requête de POST à GET pour la requête suivante. Si ce comportement n'est pas souhaité, le code d'état 307 (Temporary Redirect) peut être utilisé à la place.

Une réponse 301 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.4.3. 302 Found

Le code d'état 302 (Found) indique que la ressource cible réside temporairement sous un URI différent. Puisque la redirection peut être modifiée à l'occasion, le client devrait continuer à utiliser l'URI de requête effective pour les requêtes futures.

Le serveur DEVRAIT générer un champ d'en-tête Location dans la réponse contenant une référence URI pour l'URI différent. L'agent utilisateur PEUT utiliser la valeur du champ Location pour la redirection automatique. La charge utile de réponse du serveur contient généralement une courte note hypertexte avec un hyperlien vers le(s) URI différent(s).

Note : Pour des raisons historiques, un agent utilisateur PEUT changer la méthode de requête de POST à GET pour la requête suivante. Si ce comportement n'est pas souhaité, le code d'état 307 (Temporary Redirect) peut être utilisé à la place.

6.4.4. 303 See Other

Le code d'état 303 (See Other) indique que le serveur redirige l'agent utilisateur vers une ressource différente, comme indiqué par un URI dans le champ d'en-tête Location, qui est destinée à fournir une réponse indirecte à la requête d'origine. Un agent utilisateur peut effectuer une requête de récupération ciblant cet URI (une requête GET ou HEAD si utilisant HTTP), qui pourrait également être redirigée, et présenter le résultat éventuel comme une réponse à la requête d'origine. Notez que le nouvel URI dans le champ d'en-tête Location n'est pas considéré comme équivalent à l'URI de requête effective.

Ce code d'état est applicable à toute méthode HTTP. Il est principalement utilisé pour permettre à la sortie d'une action POST de rediriger l'agent utilisateur vers une ressource sélectionnée, car cela fournit les informations correspondant à la réponse POST sous une forme qui peut être séparément identifiée, mise en signet et mise en cache, indépendamment de la requête d'origine.

Une réponse 303 à une requête GET indique que le serveur d'origine n'a pas de représentation de la ressource cible qui peut être transférée par le serveur via HTTP. Cependant, la valeur du champ Location fait référence à une ressource qui est descriptive de la ressource cible, de sorte que faire une requête de récupération sur cette autre ressource pourrait aboutir à une représentation utile aux destinataires sans impliquer qu'elle représente la ressource cible d'origine. Notez que les réponses aux questions de ce qui peut être représenté, de quelles représentations sont adéquates et de ce qui pourrait être une description utile sont en dehors du champ d'application de HTTP.

Sauf pour les réponses à une requête HEAD, la représentation d'une réponse 303 devrait contenir une courte note hypertexte avec un hyperlien vers la même référence URI fournie dans le champ d'en-tête Location.

6.4.5. 305 Use Proxy

Le code d'état 305 (Use Proxy) a été défini dans une version antérieure de cette spécification et est maintenant déconseillé (Annexe B).

6.4.6. 306 (Unused)

Le code d'état 306 a été défini dans une version antérieure de cette spécification, n'est plus utilisé, et le code est réservé.

6.4.7. 307 Temporary Redirect

Le code d'état 307 (Temporary Redirect) indique que la ressource cible réside temporairement sous un URI différent et que l'agent utilisateur NE DOIT PAS changer la méthode de requête s'il effectue une redirection automatique vers cet URI. Puisque la redirection peut changer au fil du temps, le client devrait continuer à utiliser l'URI de requête effective d'origine pour les requêtes futures.

Le serveur DEVRAIT générer un champ d'en-tête Location dans la réponse contenant une référence URI pour l'URI différent. L'agent utilisateur PEUT utiliser la valeur du champ Location pour la redirection automatique. La charge utile de réponse du serveur contient généralement une courte note hypertexte avec un hyperlien vers le(s) URI différent(s).

Note : Ce code d'état est similaire à 302 (Found), sauf qu'il ne permet pas de changer la méthode de requête de POST à GET. Cette spécification ne définit pas de contrepartie équivalente pour 301 (Moved Permanently) ([RFC7538], cependant, définit le code d'état 308 (Permanent Redirect) à cette fin).

6.5. Client Error 4xx

La classe 4xx (Client Error) de code d'état indique que le client semble avoir commis une erreur. Sauf lorsqu'on répond à une requête HEAD, le serveur DEVRAIT envoyer une représentation contenant une explication de la situation d'erreur, et si c'est une condition temporaire ou permanente. Ces codes d'état sont applicables à toute méthode de requête. Les agents utilisateurs DEVRAIENT afficher toute représentation incluse à l'utilisateur.

6.5.1. 400 Bad Request

Le code d'état 400 (Bad Request) indique que le serveur ne peut pas ou ne veut pas traiter la requête en raison de quelque chose qui est perçu comme une erreur du client (par exemple, syntaxe de requête mal formée, cadrage de message de requête invalide, ou routage de requête trompeur).

6.5.2. 402 Payment Required

Le code d'état 402 (Payment Required) est réservé pour une utilisation future.

6.5.3. 403 Forbidden

Le code d'état 403 (Forbidden) indique que le serveur a compris la requête mais refuse de l'autoriser. Un serveur qui souhaite rendre publique la raison pour laquelle la requête a été interdite peut décrire cette raison dans la charge utile de réponse (le cas échéant).

Si des informations d'authentification ont été fournies dans la requête, le serveur les considère insuffisantes pour accorder l'accès. Le client NE DEVRAIT PAS répéter automatiquement la requête avec les mêmes informations. Le client PEUT répéter la requête avec de nouvelles informations ou différentes. Cependant, une requête pourrait être interdite pour des raisons sans rapport avec les informations.

Un serveur d'origine qui souhaite "cacher" l'existence actuelle d'une ressource cible interdite PEUT à la place répondre avec un code d'état de 404 (Not Found).

6.5.4. 404 Not Found

Le code d'état 404 (Not Found) indique que le serveur d'origine n'a pas trouvé de représentation actuelle pour la ressource cible ou n'est pas disposé à divulguer qu'une telle représentation existe. Un code d'état 404 n'indique pas si cette absence de représentation est temporaire ou permanente ; le code d'état 410 (Gone) est préféré à 404 si le serveur d'origine sait, vraisemblablement par quelque moyen configurable, que la condition est susceptible d'être permanente.

Une réponse 404 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.5.5. 405 Method Not Allowed

Le code d'état 405 (Method Not Allowed) indique que la méthode reçue dans la ligne de requête est connue par le serveur d'origine mais n'est pas prise en charge par la ressource cible. Le serveur d'origine DOIT générer un champ d'en-tête Allow dans une réponse 405 contenant une liste des méthodes actuellement prises en charge par la ressource cible.

Une réponse 405 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.5.6. 406 Not Acceptable

Le code d'état 406 (Not Acceptable) indique que la ressource cible n'a pas de représentation actuelle qui serait acceptable pour l'agent utilisateur, selon les champs d'en-tête de négociation proactive reçus dans la requête (Section 5.3), et que le serveur n'est pas disposé à fournir une représentation par défaut.

Le serveur DEVRAIT générer une charge utile contenant une liste des caractéristiques de représentation disponibles et des identifiants de ressource correspondants à partir desquels l'utilisateur ou l'agent utilisateur peut choisir celui qui est le plus approprié. Un agent utilisateur PEUT automatiquement sélectionner le choix le plus approprié de cette liste. Cependant, cette spécification ne définit aucune norme pour une telle sélection automatique, comme décrit dans Section 6.4.1.

6.5.7. 408 Request Timeout

Le code d'état 408 (Request Timeout) indique que le serveur n'a pas reçu un message de requête complet dans le temps qu'il était prêt à attendre. Un serveur DEVRAIT envoyer l'option de connexion "close" (Section 6.1 de [RFC7230]) dans la réponse, car 408 implique que le serveur a décidé de fermer la connexion plutôt que de continuer à attendre. Si le client a une requête en cours en transit, le client PEUT répéter cette requête sur une nouvelle connexion.

6.5.8. 409 Conflict

Le code d'état 409 (Conflict) indique que la requête n'a pas pu être terminée en raison d'un conflit avec l'état actuel de la ressource cible. Ce code est utilisé dans des situations où l'utilisateur pourrait être en mesure de résoudre le conflit et de soumettre à nouveau la requête. Le serveur DEVRAIT générer une charge utile qui inclut suffisamment d'informations pour qu'un utilisateur reconnaisse la source du conflit.

Les conflits sont le plus susceptibles de se produire en réponse à une requête PUT. Par exemple, si le versionnement est utilisé et que la représentation en cours de PUT inclut des modifications à une ressource qui entrent en conflit avec celles faites par une requête antérieure (par un tiers), le serveur d'origine pourrait utiliser une réponse 409 pour indiquer qu'il ne peut pas terminer la requête. Dans ce cas, la représentation de réponse contiendrait probablement des informations utiles pour fusionner les différences basées sur l'historique des révisions.

6.5.9. 410 Gone

Le code d'état 410 (Gone) indique que l'accès à la ressource cible n'est plus disponible sur le serveur d'origine et que cette condition est susceptible d'être permanente. Si le serveur d'origine ne sait pas, ou n'a pas de facilité pour déterminer, si la condition est permanente ou non, le code d'état 404 (Not Found) devrait être utilisé à la place.

La réponse 410 est principalement destinée à aider la tâche de maintenance Web en notifiant le 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 personnes qui ne sont plus associées au 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.

Une réponse 410 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.5.10. 411 Length Required

Le code d'état 411 (Length Required) indique que le serveur refuse d'accepter la requête sans un Content-Length défini (Section 3.3.2 de [RFC7230]). Le client PEUT 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.

6.5.11. 413 Payload Too Large

Le code d'état 413 (Payload Too Large) indique que le serveur refuse de traiter une requête parce que la charge utile de la requête est plus grande que ce que le serveur est disposé ou capable de traiter. Le serveur PEUT fermer la connexion pour empêcher le client de continuer la requête.

Si la condition est temporaire, le serveur DEVRAIT générer un champ d'en-tête Retry-After pour indiquer qu'elle est temporaire et après quel délai le client PEUT réessayer.

6.5.12. 414 URI Too Long

Le code d'état 414 (URI Too Long) indique que le serveur refuse de servir la requête parce que la cible de requête (Section 5.3 de [RFC7230]) est plus longue que ce que le serveur est disposé à interpréter. Cette condition rare ne se produit probablement que lorsqu'un client a improprement converti une requête POST en une 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 d'URI redirigé qui pointe vers un suffixe de lui-même), ou lorsque le serveur est attaqué par un client tentant d'exploiter des failles de sécurité.

Une réponse 414 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.5.13. 415 Unsupported Media Type

Le code d'état 415 (Unsupported Media Type) indique que le serveur d'origine refuse de servir la requête parce que la charge utile est dans un format non pris en charge par cette méthode sur la ressource cible. Le problème de format pourrait être dû au Content-Type ou Content-Encoding indiqué par la requête, ou résulter de l'inspection directe des données.

6.5.14. 417 Expectation Failed

Le code d'état 417 (Expectation Failed) indique que l'attente donnée dans le champ d'en-tête Expect de la requête (Section 5.1.1) n'a pas pu être satisfaite par au moins un des serveurs entrants.

6.5.15. 426 Upgrade Required

Le code d'état 426 (Upgrade Required) indique que le serveur refuse d'effectuer la requête en utilisant le protocole actuel mais pourrait être disposé à le faire après que le client ait migré vers un protocole différent. Le serveur DOIT envoyer un champ d'en-tête Upgrade dans une réponse 426 pour indiquer le(s) protocole(s) requis (Section 6.7 de [RFC7230]).

Exemple :

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

6.6. Server Error 5xx

La classe 5xx (Server Error) de code d'état indique que le serveur est conscient qu'il a commis une erreur ou est incapable d'exécuter la méthode demandée. Sauf lorsqu'on répond à une requête HEAD, le serveur DEVRAIT envoyer une représentation contenant une explication de la situation d'erreur, et si c'est une condition temporaire ou permanente. Un agent utilisateur DEVRAIT afficher toute représentation incluse à l'utilisateur. Ces codes d'état sont applicables à toute méthode de requête.

6.6.1. 500 Internal Server Error

Le code d'état 500 (Internal Server Error) indique que le serveur a rencontré une condition inattendue qui l'a empêché de satisfaire la requête.

6.6.2. 501 Not Implemented

Le code d'état 501 (Not Implemented) indique que 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 n'importe quelle ressource.

Une réponse 501 est mise en cache par défaut ; c'est-à-dire, sauf indication contraire par la définition de la méthode ou des contrôles de cache explicites (voir Section 4.2.2 de [RFC7234]).

6.6.3. 502 Bad Gateway

Le code d'état 502 (Bad Gateway) indique que le serveur, agissant comme une passerelle ou un proxy, a reçu une réponse invalide d'un serveur entrant qu'il a accédé en tentant de satisfaire la requête.

6.6.4. 503 Service Unavailable

Le code d'état 503 (Service Unavailable) indique que le serveur est actuellement incapable de gérer la requête en raison d'une surcharge temporaire ou d'une maintenance planifiée, qui sera probablement soulagée après un certain délai. Le serveur PEUT envoyer un champ d'en-tête Retry-After (Section 7.1.3) pour suggérer un délai approprié que le client devrait attendre avant de réessayer la requête.

Note : L'existence du code d'état 503 n'implique pas qu'un serveur doit l'utiliser lorsqu'il devient surchargé. Certains serveurs pourraient simplement refuser la connexion.

6.6.5. 504 Gateway Timeout

Le code d'état 504 (Gateway Timeout) indique que le serveur, agissant comme une passerelle ou un proxy, n'a pas reçu de réponse en temps opportun d'un serveur en amont qu'il devait accéder pour terminer la requête.

6.6.6. 505 HTTP Version Not Supported

Le code d'état 505 (HTTP Version Not Supported) indique que le serveur ne prend pas en charge, ou refuse de prendre en charge, la version majeure de HTTP qui a été utilisée dans le message de requête. Le serveur indique qu'il est incapable ou refuse de terminer la requête en utilisant la même version majeure que le client, comme décrit dans Section 2.6 de [RFC7230], autre qu'avec ce message d'erreur. Le serveur DEVRAIT générer une représentation contenant une explication de la raison pour laquelle cette version n'est pas prise en charge et quels autres protocoles sont pris en charge par ce serveur.

---