| Code d'état HTTP | Signification du code d'état |
|---|
| 100 | Le client doit continuer à envoyer des demandes. Cette réponse provisoire permet d'informer le client qu'une partie de sa requête a été reçue par le serveur et n'a pas encore été rejetée. Le client DEVRAIT continuer à envoyer le reste de la demande, ou ignorer cette réponse si la demande a déjà été complétée. Le serveur doit envoyer une réponse finale au client une fois la demande terminée. |
| 101 | Le serveur a compris la demande du client et informera le client via l'en-tête du message de mise à niveau d'utiliser un protocole différent pour terminer la demande. Après avoir envoyé la dernière ligne vierge de cette réponse, le serveur basculera vers les protocoles définis dans l'en-tête Upgrade. De telles mesures ne devraient être prises que lorsque le passage à un nouveau protocole s’avère plus bénéfique. Par exemple, le passage à une nouvelle version HTTP présente des avantages par rapport à une ancienne version, ou le passage à un protocole en temps réel et synchrone pour fournir des ressources tirant parti de ces fonctionnalités. |
| 102 | Un code d'état étendu par WebDAV (RFC 2518) indiquant que le traitement va se poursuivre. |
| 200 | La demande a abouti et les en-têtes de réponse ou le corps de données attendus par la demande seront renvoyés avec cette réponse. |
| 201 | La demande a été satisfaite, une nouvelle ressource a été créée en fonction des besoins de la demande et son URI a été renvoyée avec l'en-tête Location. Si les ressources requises ne peuvent pas être créées à temps, « 202 Accepted » doit être renvoyé. |
| 202 | Le serveur a accepté la demande mais ne l'a pas encore traitée. Tout comme elle peut être refusée, la demande peut finalement être exécutée ou non. Dans le cas d'opérations asynchrones, il n'y a pas de moyen plus pratique que d'envoyer ce code d'état. Le but du renvoi d'une réponse de code d'état 202 est de permettre au serveur d'accepter les demandes d'autres processus (comme une opération par lots qui n'est effectuée qu'une fois par jour) sans avoir à garder le client connecté au serveur jusqu'à l'opération par lots. est terminé. Une réponse qui accepte le traitement de la demande et renvoie un code d'état 202 doit contenir des informations dans l'entité renvoyée indiquant l'état actuel du traitement, 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 a été complété. |
| 203 | Le serveur a traité avec succès la demande, mais les métainformations d'en-tête d'entité renvoyées ne sont pas un ensemble défini valide sur le serveur d'origine, mais une copie provenant d'un serveur local ou tiers. Les informations actuelles peuvent être un sous-ensemble ou un sur-ensemble de la version originale. Par exemple, le fait de contenir des métadonnées pour une ressource peut amener le serveur d'origine à connaître les super informations sur les métadonnées. 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 ce code d’état. |
| 204 | Le serveur a traité avec succès la demande, mais n'a pas besoin de renvoyer le contenu de l'entité et souhaite renvoyer des méta-informations mises à jour. La réponse peut renvoyer des métainformations nouvelles ou mises à jour sous la forme d'en-têtes d'entité. Ces en-têtes, s'ils sont présents, doivent correspondre aux variables demandées. Si le client est un navigateur, le navigateur de l'utilisateur DEVRAIT conserver la page pour laquelle la demande a été faite sans aucune modification de la vue du document, même si des métainformations nouvelles ou mises à jour doivent être appliquées à l'activité du navigateur de l'utilisateur selon la spécification Documents en vue. Puisqu'il est interdit à une réponse 204 de contenir un 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é avec succès la demande et n'a rien renvoyé. Mais contrairement à une réponse 204, une réponse renvoyant ce code d'état nécessite que le demandeur réinitialise 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 l'utilisateur puisse facilement démarrer une autre saisie. Comme la réponse 204, cette réponse ne peut contenir aucun 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 comme FlashGet ou Thunder utilisent ce type de réponse pour reprendre les téléchargements interrompus ou diviser un document volumineux en plusieurs segments de téléchargement pour un téléchargement simultané. La demande doit inclure un en-tête Range pour indiquer la plage de contenu attendue par le client, et peut inclure un If-Range comme condition de demande. La réponse doit inclure les champs d'en-tête suivants : Content-Range est utilisé pour indiquer la plage de contenu renvoyée dans cette réponse ; s'il s'agit d'un téléchargement en plusieurs parties avec Content-Type multipart/byteranges, chaque partie en plusieurs parties doit contenir Content-Range. domain est utilisé pour indiquer la portée du contenu de ce paragraphe. Si un Content-Length est inclus dans la réponse, sa valeur doit correspondre au nombre réel d'octets dans la plage de contenu qu'il renvoie. Date ETag et/ou Content-Location, si la même requête aurait dû renvoyer une réponse 200. Expire, Cache-Control et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses précédentes à la même variable. Si cette demande de réponse utilise la vérification du cache fort If-Range, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité ; si cette demande de réponse utilise la vérification du cache faible If-Range, alors il est interdit à cette réponse de contenir d'autres en-têtes d'entité ; cela évite de résoudre les incohérences entre contenu de l'entité mis en cache et informations d'en-tête d'entité mises à jour. Sinon, cette réponse doit contenir tous les champs d'en-tête d'entité qui doivent être renvoyés dans une réponse 200. Si les en-têtes ETag ou Last-Modified ne correspondent pas exactement, le cache client ne doit pas combiner le contenu renvoyé par la réponse 206 avec un contenu précédemment mis en cache. Il est interdit à tout cache qui ne prend pas en charge les en-têtes Range et Content-Range de mettre en cache le contenu renvoyé par une réponse 206. |
| 207 | Le code d'état é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 indépendants en fonction du nombre de sous-requêtes précédentes. |
| 300 | La ressource demandée comporte une série de réponses facultatives, chacune avec sa propre adresse spécifique et ses propres informations de négociation du pilote de navigateur. L'utilisateur ou le navigateur peut choisir une adresse préférée pour la redirection. Sauf s'il s'agit d'une requête HEAD, la réponse doit inclure une entité avec une liste d'attributs de ressources et d'adresses à partir de laquelle l'utilisateur ou le navigateur peut choisir l'adresse de redirection la plus appropriée. Le format de cette entité est déterminé par le format défini par Content-Type. Le navigateur peut automatiquement faire le choix le plus approprié 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 une telle sélection automatique doit être effectuée. 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 Emplacement ; le navigateur peut utiliser cette valeur d'emplacement comme adresse pour la redirection automatique. De plus, cette réponse peut être mise en cache, sauf indication contraire. |
| 301 | La ressource demandée a été définitivement déplacée vers un nouvel emplacement, et toute référence future à cette ressource doit utiliser l'un des nombreux URI renvoyés avec cette réponse. Si possible, les clients dotés de capacités d'édition de liens doivent automatiquement modifier l'adresse demandée par l'adresse renvoyée par le serveur. Sauf indication contraire, cette réponse peut également être mise en cache. 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 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 interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Remarque : Pour certains navigateurs utilisant le protocole HTTP/1.0, lorsque la requête POST qu'ils envoient obtient une réponse 301, la requête de redirection suivante deviendra une méthode GET. |
| 302 | La ressource demandée répond désormais temporairement aux demandes provenant d’un autre URI. Ces redirections étant temporaires, le client doit continuer à envoyer de futures demandes à l'adresse d'origine. Cette réponse peut être mise en cache uniquement si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de 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 interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Remarque : Bien que les spécifications RFC 1945 et RFC 2068 n'autorisent pas le client à modifier la méthode de requête lors de la redirection, de nombreux navigateurs existants considèrent la réponse 302 comme une réponse 303 et utilisent la méthode GET pour accéder à l'URI spécifié dans l'emplacement, quel que soit le type de réponse. 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 demande actuelle peut être trouvée sur un autre URI et le client doit utiliser GET pour accéder à cette ressource. Cette méthode existe principalement pour permettre de rediriger la sortie de la requête POST activée par un script vers une nouvelle ressource. Ce nouvel URI n'est pas une référence de remplacement à la ressource d'origine. Dans le même temps, il est interdit de mettre en cache 303 réponses. Bien entendu, la deuxième requête (redirection) peut être mise en cache. Le nouvel URI doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. Remarque : De nombreux navigateurs antérieurs à HTTP/1.1 ne comprennent pas correctement le statut 303. Si vous devez envisager une interaction avec ces navigateurs, le code d'état 302 devrait être suffisant, car la plupart des navigateurs gèrent les réponses 302 exactement de la même manière que la spécification ci-dessus exige que les clients gèrent les réponses 303. |
| 304 | Si le client envoie une requête GET conditionnelle et que la requête est autorisée, mais que le contenu du document n'a pas changé (depuis le dernier accès ou selon les conditions de la requête), le serveur doit renvoyer ce code d'état. Il est interdit à une réponse 304 d'inclure un corps de message, elle se termine donc toujours par la première ligne vide après l'en-tête du message. La réponse DOIT contenir les informations d'en-tête suivantes : Date, sauf si le serveur ne dispose pas d'horloge. Si les serveurs sans horloge se conforment également à ces règles, alors les serveurs proxy et les clients peuvent ajouter eux-mêmes le champ Date aux en-têtes de réponse reçus (comme spécifié dans la RFC 2068), et le mécanisme de mise en cache fonctionnera normalement. ETag et/ou Content-Location, si la même requête aurait dû renvoyer une réponse 200. Expire, Cache-Control et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses précédentes à la même variable. Si cette demande de réponse utilise une vérification de cache forte, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité ; sinon (par exemple, une requête GET conditionnelle utilise une vérification de cache faible), il est interdit à cette réponse de contenir d'autres en-têtes d'entité ; cela évite de résoudre les incohérences entre les en-têtes d'entité mis en cache. contenu de l’entité et informations d’en-tête d’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 restriction. Si une réponse 304 est reçue nécessitant une mise à jour d'une entrée de cache, le système de cache doit mettre à jour l'intégralité de l'entrée pour refléter les valeurs de tous les champs qui ont été mis à jour dans la réponse. |
| 305 | La ressource demandée doit être accessible via le proxy spécifié. Les informations URI du proxy spécifié seront indiquées dans le champ Emplacement. Le destinataire doit envoyer à plusieurs reprises une demande distincte pour accéder aux ressources correspondantes via ce proxy. Seul le serveur d'origine peut établir une réponse 305. REMARQUE : La RFC 2068 ne précise pas qu'une réponse 305 est destinée à rediriger une seule requête et ne peut être établie que par le serveur d'origine. Ignorer ces restrictions peut entraîner de graves conséquences en matière de 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 aux demandes provenant d’un autre URI. Ces redirections étant temporaires, le client doit continuer à envoyer de futures demandes à l'adresse d'origine. Cette réponse peut être mise en cache uniquement si elle est spécifiée dans Cache-Control ou Expires. Le nouvel URI temporaire doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de réponse doit contenir un lien hypertexte vers le nouvel URI et une brève description. Étant donné que certains navigateurs ne peuvent pas reconnaître la réponse 307, les informations nécessaires ci-dessus doivent être ajoutées afin que les utilisateurs puissent comprendre et faire des demandes d'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 en conséquence. |
| 400 | 1. La sémantique est incorrecte et la requête actuelle ne peut pas être comprise par le serveur. Le client ne doit pas soumettre à nouveau cette demande à moins qu'elle ne soit modifiée. 2. Les paramètres de la demande sont incorrects. |
| 401 | La demande actuelle nécessite une authentification de l'utilisateur. La réponse DOIT inclure un en-tête WWW-Authenticate approprié à la ressource demandée qui demande des informations à l'utilisateur. Le client peut soumettre à plusieurs reprises une demande contenant les informations d'en-tête d'autorisation appropriées. Si la demande actuelle contient déjà des certificats d'autorisation, la réponse 401 indique que la vérification du serveur a rejeté ces certificats. Si la réponse 401 contient la même requête d'authentification que la réponse précédente et que le navigateur a tenté de s'authentifier au moins une fois, le navigateur doit afficher les informations d'entité contenues dans la réponse à l'utilisateur, car ces informations d'entité peuvent contenir des informations de diagnostic pertinentes. Voir la RFC2617. |
| 402 | Ce code d'état est réservé à d'éventuels besoins futurs. |
| 403 | Le serveur a compris la requête, mais a refusé de l'exécuter. Contrairement à une réponse 401, l’authentification n’apporte aucune aide et la 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 pourquoi la requête ne peut pas être exécutée, alors la raison du rejet doit être décrite dans l'entité. Bien entendu, le serveur peut également renvoyer une réponse 404 s’il ne souhaite pas que le client obtienne des informations. |
| 404 | La demande a échoué. La ressource demandée n’a pas été trouvée sur le serveur. Aucune information n'indique à l'utilisateur si la condition est temporaire ou permanente. Si le serveur connaît la situation, il doit utiliser le code d'état 410 pour informer que l'ancienne ressource est définitivement indisponible en raison de problèmes de mécanisme de configuration interne et qu'il n'y a pas d'adresse de saut. Le code d'état 404 est largement utilisé lorsque le serveur ne souhaite pas révéler la raison pour laquelle la demande a été rejetée ou qu'aucune autre réponse appropriée n'est disponible. |
| 405 | La méthode de requête spécifiée dans la ligne de requête ne peut pas être utilisée pour demander la ressource correspondante. La réponse doit renvoyer des informations d'en-tête Allow pour indiquer la liste des méthodes de requête que la ressource actuelle peut accepter. Étant donné que les méthodes PUT et DELETE écriront des ressources sur le serveur, la plupart des serveurs Web ne prennent pas en charge ou n'autorisent pas les méthodes de requête ci-dessus dans la configuration par défaut, et une erreur 405 sera renvoyée pour de telles requêtes. |
| 406 | Les caractéristiques de contenu de la ressource demandée ne satisfont pas aux conditions de l'en-tête de la demande, l'entité de réponse ne peut donc pas être générée. Sauf s'il s'agit d'une requête HEAD, la réponse doit renvoyer une entité contenant une liste d'attributs d'entité et d'adresses parmi lesquelles l'utilisateur ou le navigateur peut choisir celui qui est le plus approprié. Le format de l'entité est déterminé par le type de média défini dans l'en-tête Content-Type. Le navigateur peut faire son propre choix en fonction du format et de ses capacités. Cependant, la spécification ne définit aucun critère pour effectuer de telles sélections automatiques. |
| 407 | Semblable à une réponse 401, sauf que le client doit s'authentifier auprès du serveur proxy. Le serveur proxy doit renvoyer un Proxy-Authenticate pour la requête d'identité. Le client peut renvoyer un en-tête Proxy-Authorization pour vérification. Voir la RFC2617. |
| 408 | La demande a expiré. Le client n'a pas terminé l'envoi d'une requête dans le délai que le serveur était prêt à attendre. Le client peut soumettre à nouveau cette demande à tout moment sans apporter de modifications. |
| 409 | La demande ne peut pas être complétée en raison d'un conflit avec l'état actuel de la ressource demandée. Ce code ne doit être utilisé que si l'utilisateur est censé être en mesure de résoudre le conflit et de soumettre à nouveau une nouvelle demande. La réponse doit contenir suffisamment d'informations pour que l'utilisateur puisse découvrir la source du conflit. Des conflits surviennent généralement lors du traitement des requêtes PUT. Par exemple, dans un environnement utilisant la vérification de version, si les informations de version jointes à une demande de modification pour une ressource spécifique soumise par un PUT entrent en conflit avec une demande précédente (tiers), le serveur doit alors renvoyer une erreur 409. Informez l'utilisateur que la demande ne peut pas être complétée. À ce stade, l'entité de réponse est susceptible de contenir 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 aucune adresse de transfert connue. Une telle situation devrait être considérée comme permanente. Si possible, les clients disposant de capacités d'édition de 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 la condition est permanente, le code d'état 404 doit être utilisé. Sauf indication contraire, cette réponse peut être mise en cache. Le but de la réponse 410 est principalement d'aider les administrateurs du site Web à maintenir le site Web, à informer les utilisateurs que la ressource n'est plus disponible et le propriétaire du serveur espère que toutes les connexions distantes pointant vers cette ressource seront également supprimées. Ce type d’incident est courant parmi les services à valeur ajoutée à durée limitée. De même, la réponse 410 est également utilisée pour notifier au client que des ressources appartenant initialement à un individu ne sont plus disponibles sur le site serveur actuel. Bien entendu, c'est au propriétaire du serveur de décider si toutes les ressources indisponibles en permanence doivent être marquées « 410 Gone » et combien de temps elles doivent conserver cette marque. |
| 411 | Le serveur refuse d'accepter la demande 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 demande, le client peut soumettre à nouveau la demande. |
| 412 | Le serveur n'a pas rempli un ou plusieurs des prérequis indiqués dans les champs d'en-tête de la requête lors de leur validation. Ce code d'état permet au client de définir des conditions préalables dans les métainformations de la demande (données du champ d'en-tête de la demande) lors de la récupération de la ressource, empêchant ainsi que la méthode de demande soit appliquée à la ressource autrement que ce qu'elle attend. |
| 413 | Le serveur refuse de traiter la demande en cours car la demande a soumis des données d'entité plus volumineuses que ce que le serveur est disposé ou capable de gérer. Dans ce cas, le serveur peut fermer la connexion pour empêcher le client de continuer à envoyer cette requête. Si la situation est temporaire, le serveur doit renvoyer un en-tête de réponse Retry-After pour informer le client combien de temps il peut réessayer. |
| 414 | L'URI demandé est plus long que ce que le serveur peut interpréter, le serveur refuse donc de répondre à la demande. Ceci est relativement rare. Les situations courantes incluent : la soumission d'un formulaire qui devrait utiliser la méthode POST devient la méthode GET, ce qui entraîne une chaîne de requête (Query String) trop longue. Redirection de l'URI "trou noir", par exemple, chaque redirection utilise l'ancien URI dans le cadre du nouvel URI, ce qui rend l'URI trop long après plusieurs redirections. Le client tente d'attaquer le serveur en exploitant une faille de sécurité qui existe sur certains serveurs. Ce type de serveur utilise un tampon de longueur fixe pour lire ou exploiter l'URI demandé. Lorsque les paramètres après GET dépassent une certaine valeur, un débordement de tampon peut se produire, provoquant l'exécution de 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 actuellement demandées, l'entité soumise dans la demande n'est pas dans un format pris en charge par le serveur, la demande est donc rejetée. |
| 416 | Si la requête contient l'en-tête de requête Range et qu'une plage de données spécifiée dans Range ne coïncide pas avec la plage disponible de 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 statut 416. code. Si Range utilise une plage d'octets, cette situation signifie que la position du premier 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 pour indiquer la longueur de la ressource actuelle tout en renvoyant le code d'état 416. Il est également interdit à cette réponse d'utiliser des multiparts/byteranges comme Content-Type. |
| 417 | Le contenu attendu spécifié dans l'en-tête de la requête Expect ne peut pas être satisfait par le serveur, ou le serveur est un serveur proxy et il a des preuves claires que le contenu de Expect ne peut pas être satisfait sur le nœud suivant de la route actuelle. |
| 421 | Le nombre de connexions au serveur à partir de l'adresse IP du client actuel dépasse la plage maximale autorisée du serveur. Habituellement, l'adresse IP fait référence ici à l'adresse du client vue depuis le serveur (telle que l'adresse de la passerelle de l'utilisateur ou du serveur proxy). Dans ce cas, le nombre de connexions peut impliquer plusieurs utilisateurs finaux. |
| 422 | Le nombre de connexions au serveur à partir de l'adresse IP du client actuel dépasse la plage maximale autorisée du serveur. Habituellement, l'adresse IP fait référence ici à l'adresse du client vue depuis le serveur (telle que l'adresse de la passerelle de l'utilisateur ou du serveur proxy). Dans ce cas, le nombre de connexions peut impliquer plusieurs utilisateurs finaux. |
| 422 | La demande est bien formatée, mais il est impossible d'y répondre en raison d'erreurs sémantiques. (RFC 4918 WebDAV) 423 VerrouilléLa ressource actuelle est verrouillée. (RFC4918WebDAV) |
| 424 | La requête actuelle a échoué en raison d'une erreur dans une requête précédente, telle que PROPPATCH. (RFC4918WebDAV) |
| 425 | Défini dans le projet WebDav Advanced Collections, mais n'apparaît pas dans le « WebDAV Sequence Collection Protocol » (RFC 3658). |
| 426 | Les clients doivent passer à TLS/1.0. (RFC2817) |
| 449 | Étendu par Microsoft, indique que les demandes doivent être réessayées après avoir effectué les actions appropriées. |
| 500 | Le serveur a rencontré une condition inattendue qui l'a empêché de terminer le traitement de la demande. D'une manière générale, ce problème se produit lorsqu'il y a une erreur dans le code du programme du serveur. |
| 501 | Le serveur ne prend pas en charge une fonctionnalité requise par la requête actuelle. Lorsque le serveur ne reconnaît pas la méthode demandée et ne peut prendre en charge sa demande pour aucune ressource. |
| 502 | Un serveur fonctionnant comme passerelle ou proxy a reçu une réponse non valide d'un serveur en amont alors qu'il tentait d'exécuter une requête. |
| 503 | En raison d'une maintenance temporaire ou d'une surcharge du serveur, le serveur est actuellement incapable de traiter les demandes. Cette condition est temporaire et sera rétablie après un certain temps. Si le délai est prévisible, la réponse peut inclure un en-tête Retry-After pour indiquer le délai. Si ce message Retry-After n'est pas donné, le client DEVRAIT le gérer de la même manière qu'il gère une réponse 500. Remarque : La présence du code d'état 503 ne signifie pas que le serveur doit l'utiliser lorsqu'il est surchargé. Certains serveurs souhaitent simplement refuser les connexions des clients. |
| 504 | Lorsqu'un serveur fonctionnant comme passerelle ou proxy tente d'exécuter une requête, il ne parvient pas à recevoir une réponse rapide du serveur en amont (le serveur identifié par l'URI, tel que HTTP, FTP, LDAP) ou du serveur auxiliaire (tel que DNS ). Remarque : Certains serveurs proxy renvoient une erreur 400 ou 500 lorsque la requête DNS expire. |
| 505 | Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version HTTP utilisée dans la requête. Cela implique que le serveur ne peut ou ne veut pas utiliser la même version que le client. La réponse doit contenir une entité décrivant pourquoi la version n'est pas prise en charge et quels protocoles le serveur prend en charge. |
| 506 | Étendu par le protocole de négociation de contenu transparent (RFC 2295), indique que le serveur a une erreur de configuration interne : la ressource d'argument de négociation demandée est configurée pour s'utiliser elle-même dans la négociation de contenu transparente et ne constitue donc pas un objectif approprié dans un processus de négociation. |
| 507 | Le serveur ne peut pas stocker le contenu nécessaire pour compléter la demande. Cette condition est considérée comme temporaire. WebDAV (RFC4918) |
| 509 | Le serveur a atteint sa limite de bande passante. Il ne s’agit pas d’un code de statut officiel, mais il est encore largement utilisé. |
| 510 | Les stratégies nécessaires pour obtenir des ressources ne sont pas encore satisfaites. (RFC2774) |