| Code d'état HTTP | Code d'état Signification |
|---|
| 100 | Le client doit continuer à envoyer des requêtes. Cette réponse temporaire est utilisée pour informer le client qu'une partie de sa demande a été reçue par le serveur et n'a pas été rejetée. Le client doit continuer à envoyer le reste de la demande ou ignorer cette réponse si la demande est complète. Le serveur doit envoyer une réponse finale au client lorsque la demande est complète. |
| 101 | Le serveur a compris la demande du client et l'informe, par l'intermédiaire de l'en-tête du message Upgrade, qu'il doit utiliser un autre protocole pour compléter la demande. Après avoir envoyé la dernière ligne vide de cette réponse, le serveur passe aux protocoles définis dans l'en-tête du message Upgrade. Cette opération ne doit être effectuée que s'il est plus avantageux de passer à un nouveau protocole. Par exemple, le passage à une nouvelle version de HTTP est plus avantageux qu'une version plus ancienne, ou le passage à un protocole synchrone et en temps réel pour fournir des ressources qui tirent parti de ces caractéristiques. |
| 102 | Les codes d'état, étendus par WebDAV (RFC 2518), indiquent que le traitement va se poursuivre. |
| 200 | La demande a été acceptée et l'en-tête de réponse ou le corps de données souhaité par la demande sera renvoyé avec cette réponse. |
| 201 | La demande a été satisfaite, une nouvelle ressource a été créée conformément à la demande et son URI a été renvoyé avec l'en-tête Location. Si la ressource requise ne peut pas être créée à temps, la réponse doit être "202 Accepted". |
| 202 | Le serveur a accepté la demande, mais ne l'a pas encore traitée. Tout comme elle peut être rejetée, la demande peut être exécutée ou non. Dans le contexte des opérations asynchrones, il n'y a rien de plus pratique que d'envoyer ce code d'état. L'objectif du renvoi d'une réponse avec un code d'état 202 est de permettre au serveur d'accepter des demandes d'autres processus (comme une opération par lots qui n'est exécutée qu'une fois par jour) sans avoir à maintenir le client connecté au serveur jusqu'à ce que l'opération par lots soit entièrement terminée. Une réponse qui accepte une demande de traitement et renvoie un code d'état 202 DEVRAIT inclure dans l'entité renvoyée des informations indiquant l'état actuel du processus, ainsi qu'un pointeur vers un moniteur d'état de traitement ou une prédiction d'état afin que l'utilisateur puisse estimer si l'opération s'est achevée. |
| 203 | Le serveur a traité la demande avec succès, mais les méta-informations de l'en-tête de l'entité renvoyée ne sont pas un ensemble définitif valable sur le serveur d'origine, mais une copie provenant d'une partie locale ou d'une tierce partie. Les informations actuelles peuvent être un sous-ensemble ou un surensemble de la version originale. Par exemple, les métadonnées contenant des ressources peuvent amener le serveur d'origine à connaître les méta-informations super. L'utilisation de ce code d'état n'est pas obligatoire et n'est appropriée que si la réponse aurait renvoyé 200 OK sans lui. |
| 204 | Le serveur a traité la demande avec succès, mais n'a pas besoin de renvoyer de contenu physique et souhaite renvoyer des méta-informations mises à jour. La réponse peut renvoyer des méta-informations nouvelles ou mises à jour sous la forme d'en-têtes d'entité. Si de tels en-têtes existent, ils doivent correspondre aux variables demandées. Si le client est un navigateur, le navigateur de l'utilisateur DEVRAIT conserver la page sur laquelle la demande a été envoyée sans modifier la vue du document, même si, conformément à la spécification, les méta-informations nouvelles ou mises à jour DEVRAIENT être appliquées au document dans la vue active du navigateur de l'utilisateur. Comme la réponse 204 ne peut contenir aucun corps de message, elle se termine toujours par la première ligne vide après l'en-tête du message. |
| 205 | Le serveur a traité la demande avec succès et n'a rien renvoyé. Toutefois, contrairement à la réponse 204, la réponse qui renvoie ce code d'état demande au demandeur de réinitialiser la vue du document. Cette réponse est principalement utilisée pour réinitialiser le formulaire immédiatement après avoir accepté la saisie de l'utilisateur afin que ce dernier puisse facilement commencer une autre saisie. Comme la réponse 204, cette réponse ne contient pas de corps de message et se termine par la première ligne vide après l'en-tête du message. |
| 206 | Le serveur a traité avec succès une partie de la requête GET. Les outils de téléchargement HTTP tels que FlashGet ou Thunderbolt utilisent ce type de réponse pour effectuer des téléchargements intermittents ou pour diviser un document volumineux en plusieurs segments de téléchargement simultanés. La demande doit contenir un en-tête Range pour indiquer la plage de contenu que le client souhaite recevoir, et peut contenir un If-Range comme condition de demande. La réponse doit contenir les champs d'en-tête suivants : Content-Range pour indiquer l'étendue du contenu renvoyé dans cette réponse ; dans le cas d'un téléchargement en plusieurs segments avec un Content-Type de multipart/byteranges, chaque segment en plusieurs parties doit contenir un champ Content-Range indiquant l'étendue du contenu dans ce segment. Si la réponse contient un champ Content-Length, sa valeur doit correspondre au nombre réel d'octets dans la plage de contenu qu'elle renvoie. date ETag et/ou Content-Location, si la même demande aurait dû renvoyer une réponse 200. Expires, Cache-Control, et/ou Vary, si leurs valeurs peuvent être différentes de celles d'autres réponses avec les mêmes variables. Expires, Cache-Control, et/ou Vary, si leurs valeurs peuvent être différentes des valeurs d'autres réponses précédentes pour les mêmes variables. Cette réponse NE DEVRAIT PAS contenir d'autres en-têtes d'entité si la demande utilise la validation de cache forte If-Range, et NE DEVRAIT PAS contenir d'autres en-têtes d'entité si la demande utilise la validation de cache faible If-Range ; cela permet d'éviter les incohérences entre le contenu de l'entité mis en cache et les informations mises à jour de l'en-tête de l'entité. Sinon, cette réponse DEVRAIT contenir tous les champs d'en-tête d'entité qui auraient dû être renvoyés dans toutes les réponses 200 qui auraient dû être renvoyées. Si les en-têtes ETag ou Last-Modified ne correspondent pas exactement, le cache côté client DEVRAIT interdire la combinaison du contenu renvoyé dans la réponse 206 avec tout contenu précédemment mis en cache. Tout cache qui ne prend pas en charge les en-têtes Range et Content-Range n'a pas le droit de mettre en cache le contenu renvoyé par la réponse 206. |
| 207 | Le code d'état, tel qu'étendu par WebDAV (RFC 2518), signifie que le corps du message suivant sera un message XML et pourra contenir une série de codes de réponse distincts, en fonction du nombre de sous-demandes précédentes. |
| 300 | La ressource demandée dispose d'une série de messages de retour alternatifs, chacun avec sa propre adresse spécifique et des informations sur la négociation en fonction du navigateur. L'utilisateur ou le navigateur est en mesure de sélectionner lui-même l'adresse préférée pour la redirection. À moins qu'il ne s'agisse d'une requête HEAD, la réponse doit inclure une entité qui est une liste de caractéristiques et d'adresses de ressources à partir de laquelle l'utilisateur ou le navigateur peut sélectionner l'adresse de redirection la plus appropriée. Le format de cette entité est déterminé par le format de la définition Content-Type. Le navigateur peut effectuer automatiquement la sélection la plus appropriée en fonction du format de la réponse et de ses propres capacités. Bien entendu, la spécification RFC 2616 ne précise pas comment un tel choix automatique doit être effectué. Si le serveur lui-même a déjà un choix de retour préféré, l'URI de ce retour doit être spécifié dans Location ; le navigateur peut utiliser cette valeur de Location comme adresse pour la redirection automatique. En outre, cette réponse peut être mise en cache, sauf indication contraire. |
| 301 | La ressource demandée a été déplacée de manière permanente vers le nouvel emplacement, et toute référence future à cette ressource doit utiliser l'un des différents URI renvoyés dans cette réponse. Si possible, les clients dotés de capacités d'édition de liens doivent automatiquement remplacer l'adresse demandée par celle renvoyée par le serveur. Cette réponse peut également être mise en cache, sauf indication contraire. Le nouvel URI permanent doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de la réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une requête GET ou HEAD, le navigateur n'a donc pas le droit de procéder à une redirection automatique, sauf confirmation de l'utilisateur, car les termes de la requête peuvent changer en conséquence. Remarque : pour certains navigateurs utilisant le protocole HTTP/1.0, lorsqu'ils envoient une requête POST et obtiennent une réponse 301, la prochaine requête de redirection sera un GET. |
| 302 | La ressource demandée répond temporairement à la demande à partir d'un URI différent. Cette redirection étant temporaire, le client doit continuer à envoyer ses futures demandes à l'adresse d'origine. Cette réponse ne peut être mise en cache que si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Location de la réponse. À moins qu'il ne s'agisse d'une requête HEAD, l'entité de la réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une requête GET ou HEAD, il est interdit au navigateur de procéder à une redirection automatique, sauf confirmation de l'utilisateur, car les termes de la requête peuvent changer en conséquence. Note : Bien que les spécifications RFC 1945 et RFC 2068 n'autorisent pas le client à modifier la méthode de la demande lors de la redirection, de nombreux navigateurs existants traitent la réponse 302 comme une réponse 303 et utilisent GET pour accéder à l'URI spécifié dans l'emplacement, sans tenir compte de la méthode de la demande initiale. Les codes d'état 303 et 307 ont été ajoutés pour clarifier la réponse que le serveur attend du client. |
| 303 | La réponse à la requête en cours peut être trouvée dans un autre URI et le client doit accéder à cette ressource en utilisant GET. Cette méthode existe principalement pour permettre à la sortie d'une requête POST activée par un script d'être redirigée vers une nouvelle ressource. Ce nouvel URI n'est pas une référence alternative à la ressource originale. En outre, la réponse 303 ne peut pas être mise en cache. Bien entendu, la seconde demande (redirection) peut être mise en cache. Le nouvel URI doit être renvoyé dans le champ Location de la réponse. À moins qu'il ne s'agisse d'une requête HEAD, l'entité de la réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. Note : De nombreux navigateurs antérieurs aux versions HTTP/1.1 ne comprennent pas correctement l'état 303. Si une interaction avec ces navigateurs doit être envisagée, le code d'état 302 devrait suffire, car la plupart des navigateurs traitent la réponse 302 exactement de la même manière que la spécification ci-dessus exige du client qu'il traite la réponse 303. |
| 304 | Le serveur DEVRAIT renvoyer ce code d'état si le client envoie une requête GET conditionnelle qui a été autorisée et si le contenu du document (depuis la dernière visite ou selon les conditions de la requête) n'a pas changé.Les réponses 304 ne peuvent pas contenir de corps de message et se terminent donc toujours par la première ligne vide après l'en-tête du message. La réponse DOIT contenir les en-têtes suivants : Date, sauf si le serveur n'a pas d'horloge. Si un serveur sans horloge suit ces règles, le serveur mandataire et le client peuvent ajouter eux-mêmes le champ Date à l'en-tête de la réponse entrante (comme spécifié dans la RFC 2068), et le mécanisme de mise en cache fonctionnera correctement.ETag et/ou Content-Location, si la même demande aurait renvoyé une réponse 200.Expires Expires, Cache-Control, et/ou Vary, si la valeur peut être différente de la valeur correspondant à d'autres réponses précédentes pour la même variable. Si cette demande de réponse utilise une validation de cache forte, cette réponse ne doit pas contenir d'autres en-têtes d'entité ; dans le cas contraire (par exemple, une demande GET conditionnelle utilise une validation de cache faible), cette réponse ne doit pas contenir d'autres en-têtes d'entité ; cela permet d'éviter les incohérences entre le contenu de l'entité mis en cache et les informations d'en-tête de l'entité mises à jour. Si une réponse 304 indique qu'une entité n'est pas actuellement mise en cache, le système de mise en cache doit ignorer la réponse et répéter la demande sans la restriction. En cas de réception d'une réponse 304 demandant la mise à jour d'une entrée de cache, le système de mise en cache DOIT mettre à jour l'ensemble de l'entrée pour refléter les valeurs de tous les champs mis à jour dans la réponse. |
| 305 | La ressource demandée doit être accessible par l'intermédiaire du proxy spécifié. Le champ Emplacement donne des informations sur l'URI où se trouve le proxy spécifié. Le destinataire devra envoyer plusieurs fois une demande distincte pour accéder à la ressource par l'intermédiaire de ce proxy. Seul le serveur d'origine peut créer une réponse 305. Remarque : il ne ressort pas clairement de la RFC 2068 qu'une réponse 305 est destinée à rediriger une seule demande et qu'elle ne peut être créée que par le serveur d'origine. Ignorer ces restrictions pourrait avoir de graves conséquences sur la sécurité. |
| 306 | Dans la dernière version de la spécification, le code d'état 306 n'est plus utilisé. |
| 307 | La ressource demandée répond désormais temporairement à la demande à partir d'un URI différent. Ces redirections étant temporaires, les clients doivent continuer à envoyer leurs futures demandes à l'adresse d'origine. Cette réponse ne peut être mise en cache que si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Location de la réponse. À moins qu'il ne s'agisse d'une requête HEAD, l'entité de la réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. Comme certains navigateurs ne reconnaissent pas la réponse 307, les informations ci-dessus doivent être ajoutées pour que l'utilisateur puisse comprendre et demander l'accès au nouvel URI. S'il ne s'agit pas d'une requête GET ou HEAD, le navigateur interdit la redirection automatique, sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer. |
| 400 | 1. il y a une erreur sémantique et la demande actuelle ne peut pas être comprise par le serveur. Sauf modification, le client ne doit pas soumettre cette demande de manière répétée. 2. Les paramètres de la demande sont erronés. |
| 401 | La demande actuelle nécessite une authentification de l'utilisateur. La réponse doit contenir un en-tête WWW-Authenticate pour la ressource demandée afin de demander des informations sur l'utilisateur. Le client peut soumettre à plusieurs reprises une demande contenant les informations d'en-tête Authorisation appropriées. Si la demande en cours contient déjà des informations d'authentification, la réponse 401 signifie que le serveur vérifie que ces informations ont été rejetées. Si la réponse 401 contient la même demande d'authentification que la réponse précédente et que le navigateur a déjà tenté l'authentification au moins une fois, le navigateur DEVRAIT présenter à l'utilisateur les informations d'entité contenues dans la réponse, car ces informations d'entité peuvent contenir des informations de diagnostic pertinentes. Voir RFC 2617. |
| 402 | Ce code d'état est réservé pour d'éventuelles exigences futures. |
| 403 | Le serveur a compris la demande mais refuse de l'exécuter. Contrairement à une réponse 401, l'authentification n'apporte aucune aide et cette demande ne doit pas être soumise à nouveau. S'il ne s'agit pas d'une requête HEAD et que le serveur souhaite pouvoir expliquer clairement pourquoi la requête ne peut être exécutée, la raison du refus doit être décrite dans l'entité. Bien entendu, le serveur peut également renvoyer une réponse 404 s'il ne souhaite pas donner d'informations au client. |
| 404 | La requête a échoué, la ressource demandée n'a pas été trouvée sur le serveur. Aucune information ne permet à l'utilisateur de savoir si la situation est temporaire ou permanente. Si le serveur est conscient de la situation, il doit utiliser le code d'état 410 pour informer l'utilisateur que l'ancienne ressource est définitivement indisponible en raison d'un mécanisme de configuration interne et qu'aucune redirection n'est possible. 404 est largement utilisé lorsque le serveur ne souhaite pas révéler pourquoi la demande a été rejetée ou lorsqu'aucune autre réponse appropriée n'est disponible. |
| 405 | La méthode de demande spécifiée dans la ligne de demande ne peut pas être utilisée pour demander la ressource correspondante. La réponse doit renvoyer un en-tête Allow indiquant la liste des méthodes de demande acceptables pour la ressource en question. Étant donné que les méthodes PUT et DELETE écrivent dans la ressource sur le serveur, la plupart des serveurs web ne prennent pas en charge ces méthodes de demande ou ne les autorisent pas par défaut, et renverront une erreur 405 pour de telles demandes. |
| 406 | Les caractéristiques du contenu de la ressource demandée ne répondent pas aux conditions de l'en-tête de la demande et une entité de réponse ne peut être générée. À moins qu'il ne s'agisse d'une requête HEAD, la réponse doit renvoyer une entité contenant une liste de caractéristiques et d'adresses d'entités parmi lesquelles l'utilisateur ou le navigateur peut sélectionner la plus appropriée. Le format de l'entité est déterminé par le type de média défini dans l'en-tête Content-Type. Les navigateurs peuvent faire leur propre choix en fonction du format et de leurs propres capacités. Toutefois, la spécification ne définit aucun critère pour effectuer ces choix automatiques. |
| 407 | Similaire à la réponse 401, sauf que le client DOIT s'authentifier auprès du serveur proxy. Le serveur mandataire DOIT renvoyer un Proxy-Authenticate pour l'interrogation de l'identité. Le client PEUT renvoyer un en-tête Proxy-Authorization pour l'authentification. Voir RFC 2617. |
| 408 | Délai d'attente de la demande. Le client n'a pas achevé l'envoi d'une requête dans le délai d'attente prévu par le serveur. Le client peut à tout moment soumettre à nouveau la demande sans y apporter de modifications. |
| 409 | La demande n'a pas pu être achevée en raison d'un conflit avec l'état actuel de la ressource demandée. Ce code ne peut être utilisé que si l'utilisateur est jugé capable de résoudre le conflit et de soumettre une nouvelle demande. La réponse doit contenir suffisamment d'informations pour permettre à l'utilisateur de découvrir la source du conflit. Les conflits surviennent généralement lors du traitement des demandes PUT. Par exemple, dans un environnement de contrôle des versions, si les informations sur la version jointes à une requête PUT soumise pour modifier une ressource particulière entrent en conflit avec une requête précédente (tierce), le serveur doit renvoyer une erreur 409 informant l'utilisateur que la requête n'a pas pu être complétée. Dans ce cas, l'entité de réponse contiendra probablement une comparaison des différences entre les deux versions en conflit afin que l'utilisateur puisse soumettre à nouveau la nouvelle version après la fusion. |
| 410 | La ressource demandée n'est plus disponible sur le serveur et n'a pas d'adresse de réexpédition connue. Une telle situation doit être considérée comme permanente. Si possible, les clients disposant de capacités de modification des liens doivent supprimer toutes les références à cette adresse avec l'autorisation de l'utilisateur. Si le serveur ne sait pas ou ne peut pas déterminer si cette situation est permanente, il doit utiliser le code d'état 404. Sauf indication contraire, cette réponse peut être mise en cache.410 L'objectif de cette réponse est principalement d'aider le webmestre à maintenir le site en informant l'utilisateur que la ressource n'est plus disponible et que le propriétaire du serveur souhaite que toutes les connexions distantes à cette ressource soient également supprimées. Ce type d'événement est courant dans les services à valeur ajoutée limités dans le temps. De même, la réponse 410 est utilisée pour informer les clients qu'une ressource qui appartenait à l'origine à une personne sur le site du serveur actuel n'est plus disponible. Bien entendu, le propriétaire du serveur est entièrement libre de décider si toutes les ressources définitivement indisponibles doivent être marquées comme "410 Gone" et pendant combien de temps ce marquage doit être maintenu. |
| 411 | Le serveur refuse d'accepter les requêtes sans que l'en-tête Content-Length soit défini. Après avoir ajouté un en-tête Content-Length valide indiquant la longueur du corps du message de la demande, le client peut à nouveau soumettre la demande. |
| 412 | Le serveur n'a pas satisfait à une ou plusieurs conditions préalables lors de la vérification de leur présence dans le champ d'en-tête de la demande. Ce code d'état permet au client de définir des conditions préalables dans le méta-message de la demande (données du champ d'en-tête de la demande) lors de l'obtention d'une ressource, empêchant ainsi l'application de la méthode de demande à des ressources autres que le contenu souhaité. |
| 413 | Le serveur refuse de traiter la requête en cours parce qu'elle soumet des données d'entité d'une taille supérieure à celle que le serveur veut ou peut traiter. Dans ce cas, le serveur peut fermer la connexion pour empêcher le client de continuer à envoyer cette requête. Si cette situation est temporaire, le serveur doit renvoyer un en-tête de réponse Retry-After pour informer le client du délai dans lequel il peut réessayer. |
| 414 | La longueur de l'URI de la demande dépasse la longueur que le serveur peut interpréter, de sorte que le serveur refuse de servir la demande. Ce cas est rare et se produit souvent lorsqu'une soumission de formulaire qui aurait dû utiliser la méthode POST devient une méthode GET, ce qui entraîne une longue chaîne de requête. Les "trous noirs" de l'URI de redirection, tels que l'utilisation de l'ancien URI comme partie du nouvel URI à chaque redirection, ce qui entraîne un long URI après plusieurs redirections. Les clients tentent d'attaquer les serveurs en exploitant les failles de sécurité qui existent dans certains serveurs. Ces serveurs utilisent une mémoire tampon de longueur fixe pour lire ou manipuler l'URI d'une requête, et lorsque les paramètres après un GET dépassent une certaine valeur, un débordement de la mémoire tampon peut se produire, entraînant l'exécution d'un code arbitraire [1]. Les serveurs ne présentant pas de telles vulnérabilités devraient renvoyer un code d'état 414. |
| 415 | Pour la méthode et la ressource demandées actuellement, l'entité soumise dans la demande n'est pas dans un format supporté par le serveur, et la demande est donc rejetée. |
| 416 | Si la requête contient un en-tête de requête Range, que les plages de données spécifiées dans Range ne se chevauchent pas avec les plages disponibles pour la ressource actuelle et que l'en-tête de requête If-Range n'est pas défini dans la requête, le serveur doit renvoyer un code d'état 416. Si la plage utilise des plages d'octets, c'est le cas si la première position d'octet de toutes les plages de données spécifiées dans la demande dépasse la longueur de la ressource actuelle. Le serveur doit également inclure un en-tête d'entité Content-Range qui spécifie la longueur de la ressource actuelle, ainsi que le code d'état 416. Il est également interdit à cette réponse d'utiliser multipart/byteranges comme Content-Type. |
| 417 | Le contenu attendu spécifié dans l'en-tête Expect ne peut pas être satisfait par le serveur, ou ce serveur est un serveur mandataire qui a la preuve évidente que le contenu de Expect ne peut pas être satisfait au nœud suivant de la route actuelle. |
| 421 | Le nombre de connexions au serveur à partir de l'adresse IP où se trouve le client actuel dépasse le maximum autorisé par le serveur. En règle générale, l'adresse IP désigne ici l'adresse du client telle qu'elle est perçue par le serveur (par exemple, la passerelle de l'utilisateur ou l'adresse du serveur mandataire). Dans ce cas, le nombre de connexions peut concerner plus d'un utilisateur final. |
| 422 | Le nombre de connexions au serveur à partir de l'adresse IP du client actuel dépasse le maximum autorisé par le serveur. En règle générale, l'adresse IP désigne ici l'adresse du client telle qu'elle est perçue par le serveur (par exemple, la passerelle de l'utilisateur ou l'adresse du serveur mandataire). Dans ce cas, le nombre de connexions peut concerner plus d'un utilisateur final. |
| 422 | La requête a été formatée correctement, mais il n'a pas été possible d'y répondre car elle contenait des erreurs sémantiques. (RFC 4918 WebDAV) 423 Locked La ressource actuelle est verrouillée. (RFC 4918 WebDAV) |
| 424 | La requête en cours a échoué en raison d'une erreur survenue dans une requête précédente, telle que PROPPATCH.(RFC 4918 WebDAV) |
| 425 | Défini dans le projet WebDav Advanced Collections, mais n'apparaît pas dans le protocole WebDAV Sequential Collections Protocol (RFC 3658). |
| 426 | Les clients doivent passer à TLS/1.0.(RFC 2817) |
| 449 | Étendu par Microsoft pour indiquer que les requêtes doivent être réessayées après que l'action appropriée a été effectuée. |
| 500 | Le serveur a rencontré une condition imprévue qui l'a empêché de terminer le traitement de la demande. Ce problème survient généralement lorsqu'il y a une erreur dans le code du programme du serveur. |
| 501 | Le serveur ne prend pas en charge une fonctionnalité particulière requise pour la demande en cours. Lorsque le serveur n'est pas en mesure de reconnaître la méthode demandée et n'est pas en mesure de prendre en charge sa demande pour une ressource quelconque. |
| 502 | Un serveur fonctionnant comme une passerelle ou un proxy reçoit une réponse non valide d'un serveur en amont lorsqu'il tente d'exécuter une requête. |
| 503 | Le serveur est actuellement incapable de traiter la demande en raison d'une maintenance temporaire du serveur ou d'une surcharge. Cette situation est temporaire et sera rétablie après un certain temps. Si un délai est à prévoir, la réponse peut inclure un en-tête Retry-After pour indiquer le délai. Si cette information n'est pas fournie, le client doit la traiter de la même manière qu'une réponse 500. Remarque : l'existence du code d'état 503 ne signifie pas que le serveur doit l'utiliser s'il est surchargé. Certains serveurs souhaitent simplement refuser une connexion au client. |
| 504 | Un serveur fonctionnant comme une passerelle ou un proxy qui tente d'exécuter une requête ne reçoit pas de réponse en temps voulu d'un serveur en amont (un serveur identifié par un URI, tel que HTTP, FTP, LDAP) ou d'un serveur secondaire (tel que DNS). Remarque : certains serveurs mandataires renvoient une erreur 400 ou 500 lorsque la recherche DNS n'aboutit pas. |
| 505 | Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version de HTTP utilisée dans la demande. Cela signifie que le serveur ne peut pas ou ne veut pas utiliser la même version que le client. La réponse doit contenir une entité décrivant la raison pour laquelle la version n'est pas prise en charge et les protocoles pris en charge par le serveur. |
| 506 | Étendue par le protocole de négociation de contenu transparent (RFC 2295) pour représenter une mauvaise configuration interne de la part du serveur : la ressource de variante de négociation demandée est configurée pour s'utiliser elle-même dans la négociation de contenu transparent, et n'est donc pas un point d'intérêt approprié dans un processus de négociation. |
| 507 | Le serveur n'est pas en mesure de stocker le contenu nécessaire pour répondre à la demande. Cette condition est considérée comme temporaire.WebDAV (RFC 4918) |
| 509 | Le serveur a atteint sa limite de bande passante. Il ne s'agit pas d'un code d'état officiel, mais il est encore largement utilisé. |
| 510 | La politique requise pour obtenir la ressource n'a pas été non satisfaite. (RFC 2774) |