Codes de statut de réponse HTTP

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 de Création de contenu distribuée sur le Web pour indiquer qu'une requête avait été reçue par le serveur, mais qu'aucun statut n'était disponible au moment de la réponse. Le code de statut a été introduit pour la première fois dans RFC 2518, mais il a été supprimé de WebDAV dans RFC 4918. Le code de réponse a été obsolète et n'est plus utilisé.

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.

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 retourné 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.

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 mandataire. Ce code est aujourd'hui périmé pour des raisons de sécurité relatives à la configuration d'un mandataire.

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.

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