Codes de statut de réponse HTTP

Réponses informatives

Cette réponse intermédiaire indique que tout est OK pour le moment et que le client peut continuer sa requête ou l'ignorer si celle-ci est déjà finie.

Ce code est envoyé en réponse à un en-tête de requête Upgrade de la part du client et indique le protocole sur lequel passe le serveur.

Ce code était utilisé dans des contextes WebDAV pour indiquer qu'une requête a été reçue par le serveur, mais qu'aucun statut n'était disponible au moment de la réponse.

Ce code de statut est principalement destiné à être utilisé avec l'en-tête Link, permettant à l'agent utilisateur de commencer le préchargement des ressources pendant que le serveur prépare une réponse ou de préconnecter à une origine depuis laquelle la page a besoin de ressources.

Réponses de succès

La requête a réussi. La signification du succès peut varier selon la méthode HTTP :

• GET : La ressource a été récupérée et est retransmise dans le corps du message.
• HEAD : Les en-têtes d'entité sont présents dans la réponse et il n'y a pas de corps.
• PUT ou POST : 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 réussi et une nouvelle ressource a été créée en guise de résultat. Il s'agit typiquement de la réponse envoyée après une requête PUT ou POST.

La requête a été reçue mais n'a pas encore été traitée. C'est une réponse évasive, ce qui signifie qu'il n'y a aucun moyen en HTTP d'envoyer une réponse asynchrone ultérieure indiquant le résultat issu du traitement de la requête. Elle est destinée aux cas où un autre processus ou serveur gère la requête, et peut être utile pour faire du traitement par lots.

Ce code de réponse signifie que l'ensemble de méta-informations renvoyé n'est pas exactement l'ensemble disponible sur le serveur d'origine, mais plutôt un ensemble collecté à partir d'une copie locale ou tierce. Ce code est utilisé la plupart du temps par les serveurs miroirs ou de sauvegarde d'une autre ressource. À l'exception de cette condition, une réponse 200 OK est préférable.

Il n'y a pas de contenu à envoyer pour cette requête, mais les en-têtes peuvent être utiles. L'agent utilisateur peut mettre à jour ses en-têtes en cache pour cette ressource en les remplaçant par les nouveaux.

Indique à l'agent utilisateur de réinitialiser le document qui a envoyé cette requête.

Ce code de réponse est utilisé en réponse à une requête de plage lorsque le client a demandé une partie ou plusieurs parties d'une ressource.

Une réponse multi-statut donne des informations sur des ressources multiples dans les situations où les codes de statut multiples sont appropriés.

Utilisé au sein d'un élément de réponse DAV <dav:propstat> pour éviter d'énumérer à maintes reprises les membres internes de bindings multiples vers la même collection.

Le serveur a exécuté 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 courante.

Messages de redirection

Lors de la négociation de contenu pilotée par l'agent, la requête a plusieurs réponses possibles et l'agent utilisateur ou l'utilisateur·ice doit en choisir une. Il n'existe aucune méthode standardisée permettant aux clients de choisir automatiquement l'une des réponses, ce code est donc rarement utilisé.

Ce code de réponse signifie que l'URL de la ressource demandée a été modifiée. Une nouvelle URL est donnée dans la réponse.

Ce code de réponse indique que l'URI de la ressource demandée a été modifiée temporairement.

Le serveur a envoyé cette réponse pour diriger le client vers la ressource demandée par une autre URI en utilisant une requête GET.

Ce code est utilisé pour des raisons de cache. Il indique au client que la réponse n'a pas été modifiée. De fait, le client peut continuer à utiliser la même version de la réponse, mise en cache.

A été défini dans une version antérieure de la spécification HTTP pour indiquer qu'une réponse sollicitée doit transiter par un proxy. Ce code est aujourd'hui périmé pour des raisons de sécurité relatives à la configuration d'un proxy.

Ce code de réponse n'est plus en service, son usage est actuellement réservé. Il était utilisé dans une version précédente de la spécification HTTP/1.1.

Le serveur a envoyé cette réponse pour rediriger le client afin d'obtenir la ressource demandée par une autre URI, en utilisant la même méthode que précédemment. Ce code a la même sémantique que le code 302 Found, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.

Cela signifie que la ressource a été déplacée de manière permanente vers une autre URI, définie dans l'en-tête de réponse HTTP Location. Ce code a la même sémantique que le code 301 Moved Permanently, à l'exception près que l'agent utilisateur ne doit pas changer la méthode HTTP utilisée : si POST était utilisé dans la première requête, alors POST doit être utilisé dans la seconde.

Réponses d'erreur côté client

Cette réponse indique que le serveur n'a pas pu comprendre la requête à cause d'une syntaxe invalide.

Bien que le standard HTTP indique « non-autorisé », la sémantique de cette réponse correspond à « non-authentifié » . Le client doit s'authentifier afin d'obtenir la réponse demandée.

Ce code de réponse est réservé à une utilisation future. Le but initial justifiant la création de ce code était l'utilisation de systèmes de paiement numérique. Cependant, il n'est pas utilisé actuellement et aucune convention standard n'existe à ce sujet.

Le client n'a pas les droits d'accès au contenu, donc le serveur refuse de donner la véritable réponse.

Le serveur n'a pas trouvé la ressource demandée. Ce code de réponse est principalement connu pour son apparition fréquente sur le web.

La méthode de la requête est connue du serveur mais n'est pas prise en charge pour la ressource cible. Par exemple, une API peut ne pas autoriser l'utilisation du verbe DELETE pour supprimer une ressource.

Cette réponse est envoyée quand le serveur web, après une négociation de contenu géré par le serveur, ne trouve rien qui satisfasse les critères donnés par l'agent utilisateur.

Similaire au code 401, sauf que l'authentification doit être effectuée au travers d'un proxy.

Cette réponse est envoyée par une connexion en attente par certains serveurs, même sans qu'il y ait de requête préalable de la part du client. Cela signifie que le serveur aimerait fermer cette connexion inutilisée. Cette réponse est bien plus utilisée depuis que certains navigateurs, comme Chrome, Firefox 27+ ou IE9, utilisent des mécanismes de préconnexion HTTP (angl.) pour accélérer la navigation. Notez aussi que certains serveurs ferment simplement la connexion sans même envoyer ce message.

Cette réponse est envoyée lorsqu'une requête entre en conflit avec l'état actuel du serveur. Dans l'édition web distante WebDAV, les réponses 409 sont des erreurs envoyées au client afin qu'un·e utilisateur·ice puisse résoudre un conflit et renvoyer la requête.

Cette réponse est envoyée lorsque le contenu demandé a été supprimé de façon permanente du serveur, sans nouvelle adresse. Les clients doivent vider les caches et liens associés à cette ressource. La spécification HTTP a conçu ce code de statut pour qu'il soit utilisé pour des « services promotionnels limités dans le temps ». Les API ne devraient pas se sentir obligées d'indiquer que des ressources ont été supprimées avec ce code de statut.

Le serveur a rejeté la requête, car le champ d'en-tête Content-Length n'est pas défini et le serveur l'impose.

Le client a indiqué des préconditions dans ses en-têtes que le serveur ne remplit pas.

L'entité demandée est plus grosse que la limite définie par le serveur. Le serveur peut fermer la connexion ou retourner un champ d'en-tête Retry-After.

L'URI interrogé par le client est plus long que ce que le serveur est en mesure d'interpréter.

Le format média des données demandées n'est pas supporté par le serveur, donc le serveur rejette la requête.

La plage définie par le champ d'en-tête Range de la requête ne peut pas être satisfaite ; il est possible que la plage excède la taille des données provenant de l'URI ciblé.

Ce code de réponse signifie que les attentes indiquées par le champ d'en-tête de requête Expect n'ont pas pu être satisfaites par le serveur.

Le serveur refuse de brasser du café avec une théière.

La requête a été envoyée à un serveur incapable de produire une réponse. Ce code peut être envoyé par un serveur qui n'a pas été configuré pour produire des réponses sujettes à la combinaison de schémas et d'identités incluse dans l'URI de la requête.

La requête a bien été constituée mais n'a pas pu être traitée à cause d'erreurs sémantiques.

La ressource qui est en train d'être consultée est verrouillée.

La requête a échoué à cause de l'échec d'une requête précédente.

Indiquer que le serveur ne souhaite pas traiter une requête qui pourrait être rejouée.

Le serveur refuse de traiter la requête en utilisant le protocole actuel mais peut accepter de le faire si le client opte pour un autre protocole. Le serveur envoie un en-tête Upgrade dans une réponse 426 pour indiquer le ou les protocoles requis.

Le serveur d'origine impose que la requête soit conditionnelle. Ceci est prévu pour empêcher le problème de 'perte de mise à jour', où un client récupère l'état d'une ressource avec GET, le modifie, et le renvoie au serveur avec PUT pendant qu'un tiers modifie l'état du serveur, ce qui conduit à un conflit.

L'utilisateur·ice a envoyé trop de requêtes dans un laps de temps donné (limitation du débit).

Le serveur n'est pas disposé à traiter la requête, car les champs d'en-tête sont trop longs. La requête peut être renvoyée après avoir réduit la taille des en-têtes.

L'utilisateur·ice tente d'accéder à une ressource illégale, telle qu'une page censurée par un gouvernement.

Réponses d'erreur côté serveur

Le serveur a rencontré une situation qu'il ne sait pas traiter. Cette erreur est générique, indiquant que le serveur ne peut pas trouver de code de statut 5XX plus approprié pour répondre.

La méthode de requête n'est pas supportée par le serveur et ne peut pas être traitée. Les seules méthodes que les serveurs sont tenus de prendre en charge (et donc pour lesquelles ils ne peuvent pas renvoyer ce code) sont GET et HEAD.

Cette réponse d'erreur signifie que le serveur, alors qu'il fonctionnait en tant que passerelle pour recevoir une réponse nécessaire pour traiter la requête, a reçu une réponse invalide.

Le serveur n'est pas prêt pour traiter la requête. Les causes les plus communes sont que le serveur est éteint pour maintenance ou qu'il est surchargé. Notez qu'avec cette réponse, une page ergonomique peut expliquer le problème. Ces réponses doivent être utilisées temporairement et le champ d'en-tête Retry-After doit, dans la mesure du possible, contenir une estimation de l'heure de reprise du service. Le webmestre doit aussi faire attention aux en-têtes de mise en cache qui sont envoyés avec cette réponse (qui ne doivent typiquement pas être mis en cache).

Cette réponse d'erreur est renvoyée lorsque le serveur sert de passerelle et ne peut pas donner de réponse dans les temps.

La version de HTTP utilisée dans la requête n'est pas prise en charge par le serveur.

Le serveur a une erreur de configuration interne : la négociation de contenu transparente pour la requête aboutit à une dépendance circulaire.

L'action n'a pas pu être effectuée sur la ressource car le serveur est incapable de stocker la représentation nécessaire pour mener à bien la requête.

Le serveur a détecté une boucle infinie en traitant la requête.

La requête du client déclare une extension HTTP (RFC 2774) qui devrait être utilisée pour traiter la requête, mais l'extension n'est pas prise en charge.

Le code de statut 511 indique que le client doit s'authentifier afin de pouvoir accéder au réseau.

Compatibilité des navigateurs

Activez JavaScript pour afficher ce tableau de compatibilité des navigateurs.

Voir aussi

• Liste des codes de statut HTTP sur Wikipédia
• Registre officiel des codes de statut HTTP par l'IANA (angl.)