Liste des Codes d'État HTTP

Le client doit poursuivre sa requête. Cette réponse provisoire indique que tout est OK jusqu'à présent et que le client doit continuer la requête ou l'ignorer si elle est déjà terminée.

Le serveur change de protocoles comme demandé par le client via un en-tête de requête Upgrade.

WebDAV; Le serveur a reçu et traite la requête, mais aucune réponse n'est encore disponible. Cela empêche le client d'expirer et de supposer que la requête a été perdue.

Le serveur envoie certains en-têtes avant le message HTTP final. Utilisé pour permettre au client de commencer à précharger des ressources pendant que le serveur prépare encore la réponse principale.

La requête a réussi. La signification de 'réussite' dépend de la méthode HTTP : GET : La ressource a été récupérée et transmise dans le corps du message. HEAD : Les en-têtes d'entité sont dans le corps du message. POST ou PUT : La ressource décrivant le résultat de l'action est transmise dans le corps du message. TRACE : Le corps du message contient le message de requête tel que reçu par le serveur.

La requête a été traitée et a abouti à la création d'une nouvelle ressource. La nouvelle ressource est effectivement créée avant que cette réponse ne soit renvoyée et la nouvelle ressource est retournée dans le corps du message, son emplacement étant soit l'URL de la requête, soit le contenu de l'en-tête Location.

La requête a été acceptée pour traitement, mais le traitement n'est pas terminé. La requête peut ou non être finalement exécutée, car elle pourrait être refusée lorsque le traitement a effectivement lieu.

Les méta-informations retournées proviennent d'une copie locale ou tierce, et non du serveur d'origine, et pourraient être incorrectes. Sauf pour ce cas spécifique, la réponse 200 OK est préférable à ce statut.

Le serveur a traité la requête avec succès et ne retourne aucun contenu. Utile pour les actions qui ne nécessitent pas de corps de réponse, comme une requête DELETE.

Le serveur a traité la requête avec succès, demande au demandeur de réinitialiser la vue de son document et ne retourne aucun contenu. Souvent utilisé après la soumission d'un formulaire pour effacer les champs du formulaire pour une nouvelle saisie.

Le serveur ne livre qu'une partie de la ressource (service d'octets) en raison d'un en-tête de plage envoyé par le client. L'en-tête de plage est utilisé par des outils comme wget pour permettre la reprise de téléchargements interrompus ou diviser un téléchargement en plusieurs flux simultanés.

WebDAV; Transmet des informations sur plusieurs ressources, pour des situations où plusieurs codes d'état pourraient être appropriés. Le corps est un message XML.

WebDAV; Utilisé à l'intérieur d'un élément de réponse <dav:propstat> pour éviter d'énumérer à plusieurs reprises les membres internes de plusieurs liaisons à la même collection. Les membres d'une liaison ont déjà été énumérés dans une réponse précédente.

Le serveur a satisfait une requête GET pour la ressource, et la réponse est une représentation du résultat d'une ou plusieurs manipulations d'instance appliquées à l'instance actuelle. (RFC 3229)

Indique plusieurs options pour la ressource parmi lesquelles le client peut choisir (par ex. différents formats vidéo, liste de fichiers avec différentes extensions). Le serveur peut inclure un en-tête Location avec un choix préféré.

Cette requête et toutes les requêtes futures doivent être dirigées vers l'URI donnée. Les moteurs de recherche mettront à jour leurs liens vers la ressource (en 'langage SEO', on dit que le 'jus de lien' est envoyé à la nouvelle URL).

Ce code de réponse signifie que l'URI de la ressource demandée a été temporairement modifiée. D'autres modifications de l'URI pourraient être apportées à l'avenir. Par conséquent, cette même URI devrait être utilisée par le client dans les requêtes futures.

Le serveur a envoyé cette réponse pour diriger le client à obtenir la ressource demandée à une autre URI avec une requête GET. Typiquement utilisé après une opération POST/PUT pour empêcher le rafraîchissement de la page de soumettre à nouveau le formulaire.

Indique que la ressource n'a pas été modifiée depuis la version spécifiée par les en-têtes de requête If-Modified-Since ou If-None-Match. Dans ce cas, il n'est pas nécessaire de retransmettre la ressource puisque le client dispose toujours d'une copie précédemment téléchargée.

Obsolète. La ressource demandée n'est disponible que via un proxy, dont l'adresse est fournie dans la réponse. De nombreux clients HTTP (comme Mozilla Firefox et Internet Explorer) ne gèrent pas correctement les réponses avec ce code d'état, principalement pour des raisons de sécurité.

Le serveur envoie cette réponse pour diriger le client à obtenir la ressource demandée à une autre URI avec la même méthode que celle utilisée dans la requête précédente. Cela a la même sémantique que le code de réponse HTTP 302 Found, à l'exception que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée.

La ressource est maintenant située en permanence à une autre URI, spécifiée par l'en-tête de réponse HTTP Location:. Cela a la même sémantique que le code de réponse HTTP 301 Moved Permanently, à l'exception que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si un POST a été utilisé dans la première requête, un POST doit être utilisé dans la seconde requête.

Le serveur ne peut pas ou ne traitera pas la requête en raison d'une erreur apparente du client (par ex., syntaxe de requête malformée, cadrage de message de requête invalide ou routage de requête trompeur).

L'authentification est requise et a échoué ou n'a pas encore été fournie. La réponse doit inclure un champ d'en-tête WWW-Authenticate contenant un défi applicable à la ressource demandée. Parfois utilisé pour 'Autorisation échouée' mais 403 est plus approprié.

Réservé pour une utilisation future. L'intention originale était que ce code puisse être utilisé dans le cadre d'une forme de monnaie numérique ou de système de micropaiement, mais cela ne s'est pas encore produit, et ce code n'est pas largement utilisé.

La requête était valide, mais le serveur refuse d'agir. L'utilisateur peut ne pas avoir les permissions nécessaires pour une ressource, ou avoir besoin d'un compte de quelque sorte.

La ressource demandée n'a pas pu être trouvée mais pourrait être disponible à l'avenir. Les requêtes ultérieures par le client sont permises. Souvent utilisé lorsqu'un serveur ne souhaite pas révéler exactement pourquoi une requête a été refusée, ou lorsqu'aucune autre réponse n'est applicable.

Une méthode de requête n'est pas supportée pour la ressource demandée ; par exemple, une requête GET sur un formulaire qui nécessite que les données soient présentées via POST, ou une requête PUT sur une ressource en lecture seule.

La ressource demandée n'est capable de générer que du contenu non acceptable selon les en-têtes Accept envoyés dans la requête. Par exemple, le client a demandé du XML, mais le serveur ne peut fournir que du JSON.

Le client doit d'abord s'authentifier auprès du proxy. Le proxy doit envoyer un champ d'en-tête Proxy-Authenticate contenant un défi applicable au proxy pour la ressource demandée.

Le serveur a expiré en attendant la requête. Selon les spécifications HTTP : 'Le client n'a pas produit de requête dans le délai pendant lequel le serveur était prêt à attendre. Le client PEUT répéter la requête sans modifications à tout moment ultérieur.'

Indique que la requête n'a pas pu être traitée en raison d'un conflit dans l'état actuel de la ressource, tel qu'un conflit d'édition entre plusieurs mises à jour simultanées.

Indique que la ressource demandée n'est plus disponible et ne le sera plus. Ceci doit être utilisé lorsqu'une ressource a été intentionnellement supprimée et que la ressource doit être purgée. Lors de la réception d'un code d'état 410, le client ne doit plus demander la ressource à l'avenir.

La requête n'a pas spécifié la longueur de son contenu, ce qui est requis par la ressource demandée. Le serveur n'acceptera pas la requête sans un en-tête Content-Length valide.

Le serveur ne remplit pas l'une des préconditions que le demandeur a placées sur les champs d'en-tête de la requête. Ceci est souvent utilisé avec les requêtes GET conditionnelles (utilisant les en-têtes If-Match ou If-Unmodified-Since).

La requête est plus volumineuse que ce que le serveur est disposé ou capable de traiter. Anciennement appelé 'Entité de Requête Trop Volumineuse'.

L'URI fournie était trop longue pour que le serveur la traite. Souvent le résultat de trop de données encodées en tant que chaîne de requête d'une requête GET, auquel cas elle devrait être convertie en une requête POST. Anciennement appelé 'Request-URI Too Long'.

L'entité de la requête a un type de média que le serveur ou la ressource ne supporte pas. Par exemple, le client télécharge une image en tant que image/svg+xml, mais le serveur exige que les images utilisent un format différent.

Le client a demandé une portion du fichier (service d'octets), mais le serveur ne peut pas fournir cette portion. Par exemple, si le client a demandé une partie du fichier qui se trouve au-delà de la fin du fichier. Anciennement appelé 'Plage Demandée Non Satisfaisable'.

Le serveur ne peut pas satisfaire aux exigences du champ d'en-tête de requête Expect. Le client a envoyé un en-tête Expect (par ex., Expect: 100-continue) que le serveur ne peut pas satisfaire.

Ce code a été défini en 1998 comme un poisson d'avril dans la RFC 2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), et n'est pas censé être implémenté par les serveurs HTTP réels. Cependant, il est parfois utilisé comme un 'easter egg'.

La requête était dirigée vers un serveur qui n'est pas capable de produire une réponse. Cela peut être envoyé par un serveur qui n'est pas configuré pour produire des réponses pour la combinaison de schéma et d'autorité incluses dans l'URI de la requête.

WebDAV; La requête était bien formée mais n'a pas pu être suivie en raison d'erreurs sémantiques. Par exemple, un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.

WebDAV; La ressource à laquelle on accède est verrouillée. Cela signifie que la ressource source ou destination d'une méthode est verrouillée.

WebDAV; La requête a échoué car elle dépendait d'une autre requête et cette requête a échoué (par ex., un PROPPATCH avec un PROPFIND qui a échoué).

Le client doit passer à un protocole différent tel que TLS/1.0, indiqué dans le champ d'en-tête Upgrade. Le serveur envoie un en-tête Upgrade avec cette réponse pour indiquer le(s) protocole(s) requis.

Le serveur d'origine exige que la requête soit conditionnelle. Destiné à prévenir le problème de la 'mise à jour perdue', où un client obtient l'état d'une ressource, le modifie et le renvoie au serveur, alors qu'entre-temps un tiers a modifié l'état sur le serveur, entraînant un conflit.

L'utilisateur a envoyé trop de requêtes dans un laps de temps donné ('limitation de débit'). Les représentations de réponse DEVRAIENT inclure des détails expliquant la condition, et PEUVENT inclure un en-tête Retry-After indiquant combien de temps attendre avant de faire une nouvelle requête.

Le serveur n'est pas disposé à traiter la requête car ses champs d'en-tête sont trop grands. La requête PEUT être soumise à nouveau après avoir réduit la taille des champs d'en-tête de la requête.

Le serveur refuse l'accès à la ressource en conséquence d'une demande légale. Il peut s'agir d'une censure gouvernementale ou d'une ordonnance judiciaire.

Un message d'erreur générique, donné lorsqu'une condition inattendue a été rencontrée et qu'aucun message plus spécifique n'est approprié. C'est une erreur côté serveur 'fourre-tout'.

Le serveur ne reconnaît pas la méthode de requête, ou il n'a pas la capacité de satisfaire la requête. Habituellement, cela implique une disponibilité future (par ex., une nouvelle fonctionnalité d'une API de service web).

Le serveur agissait comme une passerelle ou un proxy et a reçu une réponse invalide du serveur amont auquel il a accédé en tentant de satisfaire la requête.

Le serveur est actuellement indisponible (parce qu'il est surchargé ou en maintenance). Généralement, c'est un état temporaire. Un en-tête Retry-After peut être inclus pour suggérer un délai.

Le serveur agissait comme une passerelle ou un proxy et n'a pas reçu de réponse en temps voulu du serveur amont ou d'un autre serveur auxiliaire auquel il devait accéder pour compléter la requête.

Le serveur ne supporte pas la version du protocole HTTP utilisée dans la requête. La réponse devrait contenir une entité décrivant pourquoi cette version n'est pas supportée et quels autres protocoles sont supportés par ce serveur.

La négociation de contenu transparente pour la requête aboutit à une référence circulaire. La ressource variante choisie est configurée pour s'engager elle-même dans la négociation de contenu transparente, et n'est donc pas un point final approprié dans le processus de négociation.

WebDAV; Le serveur est incapable de stocker la représentation nécessaire pour compléter la requête. Cette condition est considérée comme temporaire.

WebDAV; Le serveur a détecté une boucle infinie lors du traitement de la requête (envoyé à la place de 208 Déjà Rapporté). Cela indique que toute l'opération a échoué.

Des extensions supplémentaires à la requête sont requises pour que le serveur la satisfasse. La requête nécessite une extension obligatoire qui n'est pas supportée par le serveur.

Le client doit s'authentifier pour obtenir l'accès au réseau. Destiné à être utilisé par les proxys d'interception utilisés pour contrôler l'accès au réseau (par ex., les 'portails captifs' utilisés pour exiger l'acceptation des Conditions d'Utilisation avant d'accorder un accès complet à Internet via un hotspot Wi-Fi).