15. Status Codes (Codes de statut)

Le code de statut d'une réponse est un code entier à trois chiffres qui décrit le résultat de la requête et la sémantique de la réponse, y compris si la requête a réussi et quel contenu est inclus (le cas échéant). Tous les codes de statut valides se situent dans la plage de 100 à 599 inclus.

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

1xx (Informational): La requête a été reçue, traitement en cours
2xx (Successful): La requête a été reçue, comprise et acceptée avec succès
3xx (Redirection): D'autres actions doivent être prises pour compléter la requête
4xx (Client Error): La requête contient une syntaxe incorrecte ou ne peut pas être satisfaite
5xx (Server Error): Le serveur n'a pas pu satisfaire une requête apparemment valide

Les codes de statut HTTP sont extensibles. Un client n'est pas tenu de comprendre la signification de tous les codes de statut enregistrés, bien qu'une telle compréhension soit évidemment souhaitable. Cependant, un client DOIT comprendre la classe de tout code de statut, comme indiqué par le premier chiffre, et traiter un code de statut non reconnu comme équivalent au code de statut x00 de cette classe.

Par exemple, si un client reçoit un code de statut 471 non reconnu, il peut voir au premier chiffre 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 de statut 400 (Bad Request). Le message de réponse contiendra généralement une représentation expliquant le statut.

Les valeurs en dehors de la plage 100..599 sont invalides. Les implémentations utilisent souvent des valeurs entières à trois chiffres en dehors de cette plage (c'est-à-dire 600..999) pour la communication interne d'état non-HTTP (par exemple, erreurs de bibliothèque). Un client qui reçoit une réponse avec un code de statut invalide DEVRAIT traiter la réponse comme s'il s'agissait d'un code de statut 5xx (Server Error).

Une seule requête peut avoir plusieurs réponses associées: zéro ou plusieurs réponses "intermédiaires" (non finales) avec des codes de statut dans la plage "informational" (1xx), suivies d'exactement une réponse "finale" avec un code de statut dans l'une des autres plages.

15.1. Overview of Status Codes (Aperçu des codes de statut)

Les codes de statut énumérés ci-dessous sont définis dans cette spécification. Les phrases de raison énumérées ici ne sont que des recommandations -- elles peuvent être remplacées par des équivalents locaux ou omises complètement sans affecter le protocole.

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

Des codes de statut supplémentaires, en dehors du champ d'application de cette spécification, ont été spécifiés pour une utilisation dans HTTP. Tous ces codes de statut devraient être enregistrés dans le "Hypertext Transfer Protocol (HTTP) Status Code Registry", comme décrit dans la section 16.2.

15.2. Informational 1xx

La classe 1xx (Informational) de code de statut indique une réponse intermédiaire 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. Étant donné que HTTP/1.0 n'a défini aucun code de statut 1xx, un serveur NE DOIT PAS envoyer de réponse 1xx à un client HTTP/1.0.

Une réponse 1xx est terminée par la fin de la section d'en-tête; elle ne peut pas contenir de contenu ou de trailers.

Un client DOIT être capable d'analyser une ou plusieurs réponses 1xx reçues avant une réponse finale, même si le client n'en attend pas. Un agent utilisateur PEUT ignorer les réponses 1xx inattendues.

Un proxy DOIT transmettre 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 d'en-tête "Expect: 100-continue" lorsqu'il transmet une requête, alors il n'a pas besoin de transmettre la réponse 100 (Continue) correspondante.

15.2.1. 100 Continue

Le code de statut 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 a été complètement 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 contenu de la requête, comme décrit dans la section 10.1.1. Le client devrait continuer à envoyer la requête et ignorer la réponse 100.

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

15.2.2. 101 Switching Protocols

Le code de statut 101 (Switching Protocols) indique que le serveur comprend et est disposé à se conformer à la demande du client, via le champ d'en-tête Upgrade (section 7.8), 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/seront en vigueur après cette réponse.

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

15.3. Successful 2xx

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

15.3.1. 200 OK

Le code de statut 200 (OK) indique que la requête a réussi. Le contenu envoyé 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 du contenu peut être résumée comme suit:

Request Method	Response content is a representation of:
GET	the target resource
HEAD	the target resource, like GET, but without
	transferring the representation data
POST	the status of, or results obtained from,
	the action
PUT, DELETE	the status of the action
OPTIONS	communication options for the target
	resource
TRACE	the request message as received by the
	server returning the trace

Tableau 6

Hormis les réponses à CONNECT, une réponse 200 est censée contenir du contenu de message à moins que le cadrage du message n'indique explicitement que le contenu a une longueur nulle. Si un aspect de la requête indique une préférence pour aucun contenu en cas de succès, le serveur d'origine devrait plutôt envoyer une réponse 204 (No Content). Pour CONNECT, il n'y a pas de contenu car le résultat réussi est un tunnel, qui commence immédiatement après la section d'en-tête de la réponse 200.

Une réponse 200 est heuristiquement mis en cache; 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 [CACHING]).

Dans les réponses 200 à GET ou HEAD, un serveur d'origine DEVRAIT envoyer tous les champs de validateur disponibles (section 8.8) pour la représentation sélectionnée, avec à la fois une balise d'entité forte et une date Last-Modified étant préférées.

Dans les réponses 200 aux méthodes de changement d'état, tous les champs de validateur (section 8.8) envoyés dans la réponse véhiculent les validateurs actuels pour la nouvelle représentation formée en conséquence de l'application réussie de la sémantique de la requête. Notez que la méthode PUT (section 9.3.4) a des exigences supplémentaires qui pourraient empêcher l'envoi de tels validateurs.

15.3.2. 201 Created

Le code de statut 201 (Created) indique que la requête a été satisfaite et a conduit à 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 d'en-tête Location n'est reçu, par l'URI cible.

Le contenu de la réponse 201 décrit généralement et lie aux ressources créées. Tous les champs de validateur (section 8.8) envoyés dans la réponse véhiculent les validateurs actuels pour une nouvelle représentation créée par la requête. Notez que la méthode PUT (section 9.3.4) a des exigences supplémentaires qui pourraient empêcher l'envoi de tels validateurs.

15.3.3. 202 Accepted

Le code de statut 202 (Accepted) indique que la requête a été acceptée pour traitement, mais 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 réellement lieu. Il n'y a pas de mécanisme dans HTTP pour renvoyer un code de statut à partir 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 du moment où la requête sera satisfaite.

15.3.4. 203 Non-Authoritative Information

Le code de statut 203 (Non-Authoritative Information) indique que la requête a réussi mais le contenu joint a été modifié par rapport à celui de la réponse 200 (OK) du serveur d'origine par un proxy transformateur (section 7.7). Ce code de statut 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 demandes de validation de cache pour le contenu ne pourraient être applicables que le long du même chemin de requête (à travers les mêmes proxys).

Une réponse 203 est heuristiquement mis en cache; 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 [CACHING]).

15.3.5. 204 No Content

Le code de statut 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 contenu de la 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 de statut 204 est reçu en réponse à une requête PUT et que la réponse contient un champ ETag, alors le PUT a réussi et la valeur du champ ETag contient la balise d'entité 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 quitter 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 les nouvelles métadonnées ou mises à jour dans la réponse à sa représentation active.

Par exemple, un code de statut 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 les 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 fin de la section d'en-tête; elle ne peut pas contenir de contenu ou de trailers.

Une réponse 204 est heuristiquement mis en cache; 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 [CACHING]).

15.3.6. 205 Reset Content

Le code de statut 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 de saisie de données courant où l'utilisateur reçoit du contenu prenant en charge la saisie de données (un formulaire, bloc-notes, toile, 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 saisie suivante afin que l'utilisateur puisse facilement initier une autre action de saisie.

Étant donné que le code de statut 205 implique qu'aucun contenu supplémentaire ne sera fourni, un serveur NE DOIT PAS générer de contenu dans une réponse 205.

15.3.7. 206 Partial Content

Le code de statut 206 (Partial Content) indique que le serveur satisfait avec succès une demande de plage pour la ressource cible en transférant une ou plusieurs parties de la représentation sélectionnée.

Un serveur qui prend en charge les demandes de plage (section 14) tentera généralement de satisfaire toutes les plages demandées, car l'envoi de moins de données entraînera probablement une autre requête client pour le reste. Cependant, un serveur pourrait vouloir envoyer seulement un sous-ensemble des données demandées pour ses propres raisons, telles qu'une indisponibilité temporaire, l'efficacité du cache, l'équilibrage de charge, etc. Puisqu'une réponse 206 est auto-descriptive, le client peut toujours comprendre une réponse qui ne satisfait que partiellement sa demande de plage.

Un client DOIT inspecter les champs Content-Type et Content-Range d'une réponse 206 pour déterminer quelles parties sont incluses et si des requêtes supplémentaires sont nécessaires.

Un serveur qui génère une réponse 206 DOIT générer les champs d'en-tête suivants, en plus de ceux requis dans les sous-sections ci-dessous, si le champ aurait été envoyé dans une réponse 200 (OK) à la même requête: Date, Cache-Control, ETag, Expires, Content-Location et Vary.

Un champ d'en-tête Content-Length présent dans une réponse 206 indique le nombre d'octets dans le contenu de ce message, qui n'est généralement pas la longueur complète de la représentation sélectionnée. Chaque champ d'en-tête Content-Range inclut des informations sur la longueur complète de la représentation sélectionnée.

Un expéditeur qui génère une réponse 206 à une requête avec un champ d'en-tête If-Range NE DEVRAIT PAS générer d'autres champs d'en-tête de représentation au-delà de ceux requis car le client a déjà une réponse antérieure contenant ces champs d'en-tête. Sinon, un expéditeur DOIT générer tous les champs d'en-tête de représentation qui auraient été envoyés dans une réponse 200 (OK) à la même requête.

Une réponse 206 est heuristiquement mis en cache; c'est-à-dire, sauf indication contraire par des contrôles de cache explicites (voir section 4.2.2 de [CACHING]).

15.3.7.1. Single Part

Si une seule partie est transférée, le serveur générant la réponse 206 DOIT générer un champ d'en-tête Content-Range, décrivant quelle plage de la représentation sélectionnée est incluse, et un contenu consistant en la plage. Par exemple:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Range: bytes 21010-47021/47022 Content-Length: 26012 Content-Type: image/gif

... 26012 bytes of partial image data ...

15.3.7.2. Multiple Parts

Si plusieurs parties sont transférées, le serveur générant la réponse 206 DOIT générer un contenu "multipart/byteranges", tel que défini dans la section 14.6, et un champ d'en-tête Content-Type contenant le type de média "multipart/byteranges" et son paramètre boundary requis. Pour éviter toute confusion avec les réponses en une seule partie, un serveur NE DOIT PAS générer de champ d'en-tête Content-Range dans la section d'en-tête HTTP d'une réponse en plusieurs parties (ce champ sera envoyé dans chaque partie à la place).

Dans la zone d'en-tête de chaque partie du corps dans le contenu multipartie, le serveur DOIT générer un champ d'en-tête Content-Range correspondant à la plage incluse dans cette partie du corps. Si la représentation sélectionnée aurait eu un champ d'en-tête Content-Type dans une réponse 200 (OK), le serveur DEVRAIT générer ce même champ d'en-tête Content-Type dans la zone d'en-tête de chaque partie du corps. Par exemple:

HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-Length: 1741 Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 500-999/8000

...the first range... --THIS_STRING_SEPARATES Content-Type: application/pdf Content-Range: bytes 7000-7999/8000

...the second range --THIS_STRING_SEPARATES--

Lorsque plusieurs plages sont demandées, un serveur PEUT fusionner toutes les plages qui se chevauchent, ou qui sont séparées par un écart inférieur à la surcharge d'envoi de plusieurs parties, quel que soit l'ordre dans lequel la spécification de plage correspondante est apparue dans le champ d'en-tête Range reçu. Étant donné que la surcharge typique entre chaque partie d'un "multipart/byteranges" est d'environ 80 octets, en fonction du type de média de la représentation sélectionnée et de la longueur du paramètre boundary choisi, il peut être moins efficace de transférer de nombreuses petites parties disjointes que de transférer la représentation sélectionnée entière.

Un serveur NE DOIT PAS générer de réponse multipartie à une requête pour une seule plage, car un client qui ne demande pas plusieurs parties pourrait ne pas prendre en charge les réponses multiparties. Cependant, un serveur PEUT générer une réponse "multipart/byteranges" avec une seule partie de corps si plusieurs plages ont été demandées et qu'une seule plage s'est avérée satisfaisable ou qu'une seule plage est restée après fusion. Un client qui ne peut pas traiter une réponse "multipart/byteranges" NE DOIT PAS générer de requête demandant plusieurs plages.

Un serveur qui génère une réponse multipartie DEVRAIT envoyer les parties dans le même ordre que la spécification de plage correspondante est apparue dans le champ d'en-tête Range reçu, à l'exception des plages jugées non satisfaisables ou fusionnées dans d'autres plages. Un client qui reçoit une réponse multipartie DOIT inspecter le champ d'en-tête Content-Range présent dans chaque partie du corps pour déterminer quelle plage est contenue dans cette partie du corps; un client ne peut pas compter recevoir les mêmes plages qu'il a demandées, ni le même ordre qu'il a demandé.

15.3.7.3. Combining Parts

Une réponse peut ne transférer qu'une sous-plage d'une représentation si la connexion s'est fermée prématurément ou si la requête a utilisé une ou plusieurs spécifications de plage. Après plusieurs de ces transferts, un client peut avoir reçu plusieurs plages de la même représentation. Ces plages ne peuvent être combinées en toute sécurité que si elles ont toutes en commun le même validateur fort (section 8.8.1).

Un client qui a reçu plusieurs réponses partielles aux requêtes GET sur une ressource cible PEUT combiner ces réponses en une plage continue plus large si elles partagent le même validateur fort.

Si la réponse la plus récente est une réponse 200 (OK) incomplète, alors les champs d'en-tête de cette réponse sont utilisés pour toute réponse combinée et remplacent ceux des réponses stockées correspondantes.

Si la réponse la plus récente est une réponse 206 (Partial Content) et qu'au moins une des réponses stockées correspondantes est une 200 (OK), alors les champs d'en-tête de réponse combinés consistent en les champs d'en-tête de la réponse 200 la plus récente. Si toutes les réponses stockées correspondantes sont des réponses 206, alors la réponse stockée avec les champs d'en-tête les plus récents est utilisée comme source des champs d'en-tête pour la réponse combinée, sauf que le client DOIT utiliser d'autres champs d'en-tête fournis dans la nouvelle réponse, en dehors de Content-Range, pour remplacer toutes les instances du champ d'en-tête correspondant dans la réponse stockée.

Le contenu de réponse combiné consiste en l'union des plages de contenu partiel dans la nouvelle réponse et toutes les réponses stockées correspondantes. Si l'union consiste en la plage entière de la représentation, alors le client DOIT traiter la réponse combinée comme s'il s'agissait d'une réponse 200 (OK) complète, y compris un champ d'en-tête Content-Length qui reflète la longueur complète. Sinon, le client DOIT traiter l'ensemble des plages continues comme l'une des suivantes: une réponse 200 (OK) incomplète si la réponse combinée est un préfixe de la représentation, une seule réponse 206 (Partial Content) contenant du contenu "multipart/byteranges", ou plusieurs réponses 206 (Partial Content), chacune avec une plage continue qui est indiquée par un champ d'en-tête Content-Range.

15.4. Redirection 3xx

La classe 3xx (Redirection) de code de statut indique que d'autres actions doivent être prises par l'agent utilisateur pour satisfaire la requête. Il existe plusieurs types de redirections:

Redirections qui indiquent que cette ressource pourrait être disponible à un URI différent, tel que fourni par le champ d'en-tête Location, comme dans les codes de statut 301 (Moved Permanently), 302 (Found), 307 (Temporary Redirect) et 308 (Permanent Redirect).
Redirection qui offre un choix parmi les ressources correspondantes capables de représenter cette ressource, comme dans le code de statut 300 (Multiple Choices).
Redirection vers une ressource différente, identifiée par le champ d'en-tête Location, qui peut représenter une réponse indirecte à la requête, comme dans le code de statut 303 (See Other).
Redirection vers un résultat précédemment stocké, comme dans le code de statut 304 (Not Modified).

| Note: Dans HTTP/1.0, les codes de statut 301 (Moved Permanently) | et 302 (Found) ont été initialement définis comme préservant la | méthode ([HTTP/1.0], section 9.3) pour correspondre à leur | implémentation au CERN; 303 (See Other) a été défini pour une | redirection qui changeait sa méthode en GET. Cependant, les premiers | agents utilisateurs se sont divisés sur la question de savoir s'il | fallait rediriger les requêtes POST en POST (selon la spécification | alors en vigueur) ou en GET (l'alternative plus sûre lors de la | redirection vers un site différent). La pratique dominante a | finalement convergé vers le changement de la méthode en GET. 307 | (Temporary Redirect) et 308 (Permanent Redirect) [RFC7538] ont été | ajoutés plus tard pour indiquer sans ambiguïté les redirections | préservant la méthode, et les codes de statut 301 et 302 ont été | ajustés pour permettre qu'une requête POST soit redirigée en GET.

Si un champ d'en-tête Location (section 10.2.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 de statut spécifique n'est pas compris. La redirection automatique doit être effectuée avec prudence pour les méthodes qui ne sont pas connues pour être sûres, comme défini dans la section 9.2.1, car l'utilisateur pourrait ne pas souhaiter rediriger une requête non sûre.

Lors du suivi automatique d'une requête redirigée, l'agent utilisateur DEVRAIT renvoyer le message de requête d'origine avec les modifications suivantes:

Remplacez l'URI cible par l'URI référencé par la valeur du champ d'en-tête Location de la réponse de redirection après l'avoir résolu par rapport à l'URI cible de la requête d'origine.
Supprimez les champs d'en-tête qui ont été générés automatiquement par l'implémentation, en les remplaçant par des valeurs mises à jour appropriées à la nouvelle requête. Cela inclut:
1. Les champs d'en-tête spécifiques à la connexion (voir section 7.6.1),
2. Les champs d'en-tête spécifiques à la configuration du proxy du client, y compris (mais sans s'y limiter) Proxy-Authorization,
3. Les champs d'en-tête spécifiques à l'origine (le cas échéant), y compris (mais sans s'y limiter) Host,
4. Les champs d'en-tête de validation qui ont été ajoutés par le cache de l'implémentation (par exemple, If-None-Match, If-Modified-Since), et
5. Les champs d'en-tête spécifiques à la ressource, y compris (mais sans s'y limiter) Referer, Origin, Authorization et Cookie.
Envisagez de supprimer les champs d'en-tête qui n'ont pas été générés automatiquement par l'implémentation (c'est-à-dire ceux présents dans la requête parce qu'ils ont été ajoutés par le contexte appelant) où il y a des implications de sécurité; cela inclut mais n'est pas limité à Authorization et Cookie.
Changez la méthode de requête selon la sémantique du code de statut de redirection, le cas échéant.
Si la méthode de requête a été changée en GET ou HEAD, supprimez les champs d'en-tête spécifiques au contenu, y compris (mais sans s'y limiter) Content-Encoding, Content-Language, Content-Location, Content-Type, Content-Length, Digest, Last-Modified.

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.

15.4.1. 300 Multiple Choices

Le code de statut 300 (Multiple Choices) indique que la ressource cible a plus d'une représentation, chacune avec son propre identifiant plus spécifique, et 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 ou les représentations les plus appropriées à ses besoins (section 12).

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 une redirection automatique.

Pour les méthodes de requête autres que HEAD, le serveur DEVRAIT générer du contenu dans la réponse 300 contenant une liste de métadonnées de représentation et de références 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 automatique dans cette liste 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 tente de rester orthogonal à la définition de son contenu. En pratique, la représentation est fournie dans un format facilement analysable jugé 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 heuristiquement mis en cache; 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 [CACHING]).

| Note: La proposition originale pour le code de statut 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 les désaccords sur la syntaxe | ont conduit à ce que URI et Alternates (une proposition ultérieure) | soient abandonnés de cette spécification. Il est possible de | communiquer la liste comme une valeur de champ d'en-tête Link [RFC8288] | dont les membres ont une relation "alternate", bien que le déploiement | soit un problème d'œuf et de poule.

15.4.2. 301 Moved Permanently

Le code de statut 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 joints. Le serveur suggère qu'un agent utilisateur avec une capacité d'édition de liens peut remplacer en permanence les références à l'URI cible par l'une des nouvelles références envoyées par le serveur. Cependant, cette suggestion est généralement ignorée à moins que l'agent utilisateur ne modifie activement les références (par exemple, engagé dans la création de contenu), que la connexion ne soit sécurisée et que le serveur d'origine ne soit une autorité de confiance pour le contenu en cours d'édition.

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 une redirection automatique. Le contenu de réponse du serveur contient généralement une note hypertexte courte avec un hyperlien vers le ou les nouveaux URI.

| Note: Pour des raisons historiques, un agent utilisateur PEUT changer | la méthode de requête de POST à GET pour la requête ultérieure. Si ce | comportement n'est pas souhaité, le code de statut 308 (Permanent | Redirect) peut être utilisé à la place.

Une réponse 301 est heuristiquement mis en cache; 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 [CACHING]).

15.4.3. 302 Found

Le code de statut 302 (Found) indique que la ressource cible réside temporairement sous un URI différent. Étant donné que la redirection peut être modifiée à l'occasion, le client devrait continuer à utiliser l'URI cible 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 une redirection automatique. Le contenu de réponse du serveur contient généralement une note hypertexte courte avec un hyperlien vers le ou les URI différents.

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

15.4.4. 303 See Other

Le code de statut 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 vous utilisez HTTP), qui peut é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 cible.

Ce code de statut 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 différente, car cela fournit les informations correspondant à la réponse POST en tant que ressource qui peut être identifiée, marquée et mise en cache séparément.

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 sur 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 pour les 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é, quelles représentations sont adéquates et 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 note hypertexte courte avec un hyperlien vers la même référence URI fournie dans le champ d'en-tête Location.

15.4.5. 304 Not Modified

Le code de statut 304 (Not Modified) indique qu'une requête GET ou HEAD conditionnelle a été reçue et aurait abouti à une réponse 200 (OK) s'il n'y avait pas eu le fait que la condition a été évaluée à faux. En d'autres termes, il n'est pas nécessaire pour le serveur de transférer une représentation de la ressource cible car la requête indique que le client, qui a rendu la requête conditionnelle, a déjà une représentation valide; le serveur redirige donc le client pour utiliser cette représentation stockée comme si c'était le contenu d'une réponse 200 (OK).

Le serveur générant une réponse 304 DOIT générer l'un des champs d'en-tête suivants qui aurait été envoyé dans une réponse 200 (OK) à la même requête:

Content-Location, Date, ETag et Vary
Cache-Control et Expires (voir [CACHING])

Puisque le but d'une réponse 304 est de minimiser le transfert d'informations lorsque le destinataire a déjà une ou plusieurs représentations mises en cache, un expéditeur NE DEVRAIT PAS générer de métadonnées de représentation autres que les champs énumérés ci-dessus à moins que lesdites métadonnées n'existent dans le but de guider les mises à jour du cache (par exemple, Last-Modified pourrait être utile si la réponse n'a pas de champ ETag).

Les exigences sur un cache qui reçoit une réponse 304 sont définies dans la section 4.3.4 de [CACHING]. Si la requête conditionnelle provient d'un client sortant, tel qu'un agent utilisateur avec son propre cache envoyant un GET conditionnel à un proxy partagé, alors le proxy DEVRAIT transmettre la réponse 304 à ce client.

Une réponse 304 est terminée par la fin de la section d'en-tête; elle ne peut pas contenir de contenu ou de trailers.

15.4.6. 305 Use Proxy

Le code de statut 305 (Use Proxy) a été défini dans une version précédente de cette spécification et est maintenant obsolète (Annexe B de [RFC7231]).

15.4.7. 306 (Unused)

Le code de statut 306 a été défini dans une version précédente de cette spécification, n'est plus utilisé et le code est réservé.

15.4.8. 307 Temporary Redirect

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

15.4.9. 308 Permanent Redirect

Le code de statut 308 (Permanent Redirect) 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 joints. Le serveur suggère qu'un agent utilisateur avec une capacité d'édition de liens peut remplacer en permanence les références à l'URI cible par l'une des nouvelles références envoyées par le serveur. Cependant, cette suggestion est généralement ignorée à moins que l'agent utilisateur ne modifie activement les références (par exemple, engagé dans la création de contenu), que la connexion ne soit sécurisée et que le serveur d'origine ne soit une autorité de confiance pour le contenu en cours d'édition.

Une réponse 308 est heuristiquement mis en cache; 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 [CACHING]).

| Note: Ce code de statut est beaucoup plus jeune (juin 2014) que ses | codes frères et peut donc ne pas être reconnu partout. Voir la section | 4 de [RFC7538] pour les considérations de déploiement.

15.5. Client Error 4xx

La classe 4xx (Client Error) de code de statut indique que le client semble avoir commis une erreur. Sauf lors de la réponse à 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 de statut sont applicables à toute méthode de requête. Les agents utilisateurs DEVRAIENT afficher toute représentation incluse à l'utilisateur.

15.5.1. 400 Bad Request

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

15.5.2. 401 Unauthorized

Le code de statut 401 (Unauthorized) indique que la requête n'a pas été appliquée car elle manque d'informations d'authentification valides pour la ressource cible. Le serveur générant une réponse 401 DOIT envoyer un champ d'en-tête WWW-Authenticate (section 11.6.1) contenant au moins un défi applicable à la ressource cible.

Si la requête comprenait des informations d'authentification, alors la réponse 401 indique que l'autorisation a été refusée pour ces informations. L'agent utilisateur PEUT répéter la requête avec un nouveau champ d'en-tête Authorization ou remplacé (section 11.6.2). Si la réponse 401 contient le même défi que la réponse précédente, et que l'agent utilisateur a déjà tenté l'authentification au moins une fois, alors l'agent utilisateur DEVRAIT présenter la représentation jointe à l'utilisateur, car elle contient généralement des informations de diagnostic pertinentes.

15.5.3. 402 Payment Required

Le code de statut 402 (Payment Required) est réservé pour une utilisation future.

15.5.4. 403 Forbidden

Le code de statut 403 (Forbidden) indique que le serveur a compris la requête mais refuse de la satisfaire. Un serveur qui souhaite rendre public pourquoi la requête a été interdite peut décrire cette raison dans le contenu de la réponse (le cas échéant).

Si des informations d'authentification ont été fournies dans la requête, le serveur les considère comme 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 des informations nouvelles ou différentes. Cependant, une requête peut ê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 plutôt répondre avec un code de statut 404 (Not Found).

15.5.5. 404 Not Found

Le code de statut 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 existe. Un code de statut 404 n'indique pas si cette absence de représentation est temporaire ou permanente; le code de statut 410 (Gone) est préféré à 404 si le serveur d'origine sait, probablement par un moyen configurable, que la condition est susceptible d'être permanente.

Une réponse 404 est heuristiquement mis en cache; 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 [CACHING]).

15.5.6. 405 Method Not Allowed

Le code de statut 405 (Method Not Allowed) indique que la méthode reçue dans la ligne de requête est connue du 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 heuristiquement mis en cache; 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 [CACHING]).

15.5.7. 406 Not Acceptable

Le code de statut 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 12.1), et le serveur n'est pas disposé à fournir une représentation par défaut.

Le serveur DEVRAIT générer du contenu contenant une liste des caractéristiques de représentation disponibles et des identificateurs de ressources correspondants à partir desquels l'utilisateur ou l'agent utilisateur peut choisir le plus approprié. Un agent utilisateur PEUT sélectionner automatiquement le choix le plus approprié dans cette liste. Cependant, cette spécification ne définit aucune norme pour une telle sélection automatique, comme décrit dans la section 15.4.1.

15.5.8. 407 Proxy Authentication Required

Le code de statut 407 (Proxy Authentication Required) est similaire à 401 (Unauthorized), mais il indique que le client doit s'authentifier pour utiliser un proxy pour cette requête. Le proxy DOIT envoyer un champ d'en-tête Proxy-Authenticate (section 11.7.1) contenant un défi applicable à ce proxy pour la requête. Le client PEUT répéter la requête avec un nouveau champ d'en-tête Proxy-Authorization ou remplacé (section 11.7.2).

15.5.9. 408 Request Timeout

Le code de statut 408 (Request Timeout) indique que le serveur n'a pas reçu de message de requête complet dans le temps qu'il était prêt à attendre.

Si le client a une requête en attente en transit, il PEUT répéter cette requête. Si la connexion actuelle n'est pas utilisable (par exemple, comme ce serait le cas dans HTTP/1.1 car la délimitation de requête est perdue), une nouvelle connexion sera utilisée.

15.5.10. 409 Conflict

Le code de statut 409 (Conflict) indique que la requête n'a pas pu être complété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 du contenu qui inclut suffisamment d'informations pour qu'un utilisateur reconnaisse la source du conflit.

Les conflits sont les plus susceptibles de se produire en réponse à une requête PUT. Par exemple, si le contrôle de version était utilisé et que la représentation en cours de PUT incluait des modifications à une ressource qui entrent en conflit avec celles apportées par une requête antérieure (tierce), 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 en fonction de l'historique des révisions.

15.5.11. 410 Gone

Le code de statut 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 aucun moyen de déterminer, si la condition est permanente ou non, le code de statut 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 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 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 heuristiquement mis en cache; 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 [CACHING]).

15.5.12. 411 Length Required

Le code de statut 411 (Length Required) indique que le serveur refuse d'accepter la requête sans un Content-Length défini (section 8.6). 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 contenu de la requête.

15.5.13. 412 Precondition Failed

Le code de statut 412 (Precondition Failed) indique qu'une ou plusieurs conditions données dans les champs d'en-tête de requête ont été évaluées à faux lors du test sur le serveur (section 13). Ce code de statut de réponse permet au client de placer des conditions préalables sur l'état de ressource actuel (ses représentations et métadonnées actuelles) et, ainsi, d'empêcher la méthode de requête d'être appliquée si la ressource cible est dans un état inattendu.

15.5.14. 413 Content Too Large

Le code de statut 413 (Content Too Large) indique que le serveur refuse de traiter une requête car le contenu de la requête est plus grand que le serveur est disposé ou capable de traiter. Le serveur PEUT mettre fin à la requête, si la version du protocole utilisée le permet; sinon, le serveur PEUT fermer la connexion.

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 moment le client PEUT réessayer.

15.5.15. 414 URI Too Long

Le code de statut 414 (URI Too Long) indique que le serveur refuse de servir la requête car l'URI cible est plus long que le serveur est disposé à interpréter. Cette condition rare ne se produit probablement que lorsqu'un client a incorrectement converti une requête POST en requête GET avec des informations de requête longues, lorsque le client est descendu dans une boucle infinie de redirection (par exemple, un préfixe 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é potentielles.

Une réponse 414 est heuristiquement mis en cache; 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 [CACHING]).

15.5.16. 415 Unsupported Media Type

Le code de statut 415 (Unsupported Media Type) indique que le serveur d'origine refuse de servir la requête car le contenu est dans un format non pris en charge par cette méthode sur la ressource cible.

Le problème de format peut être dû au Content-Type ou Content-Encoding indiqué de la requête, ou suite à l'inspection directe des données.

Si le problème était causé par un codage de contenu non pris en charge, le champ d'en-tête de réponse Accept-Encoding (section 12.5.3) devrait être utilisé pour indiquer quel(s) codage(s) de contenu aurait été accepté(s) dans la requête.

D'un autre côté, si la cause était un type de média non pris en charge, le champ d'en-tête de réponse Accept (section 12.5.1) peut être utilisé pour indiquer quels types de média auraient été acceptés dans la requête.

15.5.17. 416 Range Not Satisfiable

Le code de statut 416 (Range Not Satisfiable) indique que l'ensemble des plages dans le champ d'en-tête Range de la requête (section 14.2) a été rejeté soit parce qu'aucune des plages demandées n'est satisfaisable, soit parce que le client a demandé un nombre excessif de plages petites ou chevauchantes (une attaque potentielle par déni de service).

Chaque unité de plage définit ce qui est requis pour que ses propres ensembles de plages soient satisfaisables. Par exemple, la section 14.1.2 définit ce qui rend un ensemble de plages d'octets satisfaisable.

Un serveur qui génère une réponse 416 à une requête de plage d'octets DEVRAIT générer un champ d'en-tête Content-Range spécifiant la longueur actuelle de la représentation sélectionnée (section 14.4).

Par exemple:

HTTP/1.1 416 Range Not Satisfiable Date: Fri, 20 Jan 2012 15:41:54 GMT Content-Range: bytes */47022

| Note: Étant donné que les serveurs sont libres d'ignorer Range, de | nombreuses implémentations répondront avec la représentation | sélectionnée entière dans une réponse 200 (OK). C'est en partie parce | que la plupart des clients sont préparés à recevoir une 200 (OK) pour | terminer la tâche (bien que moins efficacement) et en partie parce que | les clients pourraient ne pas arrêter de faire une requête de plage | invalide tant qu'ils n'ont pas reçu une représentation complète. Ainsi, | les clients ne peuvent pas compter recevoir une réponse 416 (Range Not | Satisfiable) même lorsqu'elle est la plus appropriée.

15.5.18. 417 Expectation Failed

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

15.5.19. 418 (Unused)

[RFC2324] était un RFC du 1er avril qui se moquait des différentes façons dont HTTP était abusé; un tel abus était la définition d'un code de statut 418 spécifique à l'application, qui a été déployé comme une blague assez souvent pour que le code soit inutilisable pour toute utilisation future.

Par conséquent, le code de statut 418 est réservé dans le registre des codes de statut HTTP de l'IANA. Cela indique que le code de statut ne peut actuellement pas être attribué à d'autres applications. Si de futures circonstances nécessitent son utilisation (par exemple, l'épuisement des codes de statut 4NN), il peut être réattribué à une autre utilisation.

15.5.20. 421 Misdirected Request

Le code de statut 421 (Misdirected Request) indique que la requête a été dirigée vers un serveur qui est incapable ou peu disposé à produire une réponse autoritaire pour l'URI cible. Un serveur d'origine (ou une passerelle agissant au nom du serveur d'origine) envoie 421 pour rejeter une URI cible qui ne correspond pas à une origine pour laquelle le serveur a été configuré (section 4.3.1) ou ne correspond pas au contexte de connexion sur lequel la requête a été reçue (section 7.4).

Un client qui reçoit une réponse 421 (Misdirected Request) PEUT réessayer la requête, que la méthode de requête soit idempotente ou non, sur une connexion différente, telle qu'une nouvelle connexion spécifique à l'origine de la ressource cible, ou via un service alternatif [ALTSVC].

Un proxy NE DOIT PAS générer de réponse 421.

15.5.21. 422 Unprocessable Content

Le code de statut 422 (Unprocessable Content) indique que le serveur comprend le type de contenu du contenu de la requête (par conséquent, un code de statut 415 (Unsupported Media Type) est inapproprié), et la syntaxe du contenu de la requête est correcte, mais il n'a pas pu traiter les instructions contenues. Par exemple, ce code de statut peut être envoyé si un contenu de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

15.5.22. 426 Upgrade Required

Le code de statut 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 passe à un protocole différent. Le serveur DOIT envoyer un champ d'en-tête Upgrade dans une réponse 426 pour indiquer le ou les protocoles requis (section 7.8).

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.

15.6. Server Error 5xx

La classe 5xx (Server Error) de code de statut indique que le serveur est conscient qu'il a commis une erreur ou est incapable d'exécuter la méthode demandée. Sauf lors de la réponse à 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 de statut sont applicables à toute méthode de requête.

15.6.1. 500 Internal Server Error

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

15.6.2. 501 Not Implemented

Le code de statut 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 une ressource quelconque.

Une réponse 501 est heuristiquement mis en cache; 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 [CACHING]).

15.6.3. 502 Bad Gateway

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

15.6.4. 503 Service Unavailable

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

| Note: L'existence du code de statut 503 n'implique pas qu'un serveur | doive l'utiliser en cas de surcharge. Certains serveurs pourraient | simplement refuser la connexion.

15.6.5. 504 Gateway Timeout

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

15.6.6. 505 HTTP Version Not Supported

Le code de statut 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 peu disposé à terminer la requête en utilisant la même version majeure que le client, comme décrit dans la section 2.5, autre qu'avec ce message d'erreur. Le serveur DEVRAIT générer une représentation pour la réponse 505 qui décrit pourquoi cette version n'est pas prise en charge et quels autres protocoles sont pris en charge par ce serveur.