Outils en ligne
Codes 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 Upgrade, qu'un protocole différent a été utilisé pour compléter la demande. Après avoir envoyé la dernière ligne vide de la réponse, le serveur passe aux protocoles définis dans l'en-tête Upgrade. Cette opération ne doit être effectuée que s'il est plus avantageux de passer au nouveau protocole. Par exemple, le passage à une nouvelle version de HTTP peut être plus avantageux qu'une version plus ancienne, ou le passage à un protocole synchrone 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 les en-têtes de réponse ou le corps de données souhaités par la demande seront renvoyés avec la réponse.
201 La demande a été satisfaite, une nouvelle ressource a été créée en réponse à la demande et son URI a été renvoyé avec l'en-tête Location. Si la ressource demandée ne peut pas être créée à temps, le message suivant doit être renvoyé'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 cas d'opérations asynchrones, il n'y a rien de plus pratique que d'envoyer ce code d'état. Le renvoi d'une réponse 202 a pour but 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 que le client ne doive maintenir une connexion avec le serveur jusqu'à ce que l'opération par lots soit terminée. Une réponse qui accepte une demande de traitement et renvoie un code d'état 202 doit 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 ou non.
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 l'original. 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 ces 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 aucune modification de la vue du document, même si les méta-informations nouvelles ou mises à jour DEVRAIENT, conformément à la spécification, ê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 traite la demande avec succès et ne renvoie rien. Cependant, 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 fractionner un fichier volumineux en plusieurs téléchargements 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 ou, dans le cas de téléchargements en plusieurs parties avec un Content-Type de multipart/byteranges, un champ Content-Range dans chaque segment en plusieurs parties pour indiquer 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 renvoyée. Expires, Cache-Control, et/ou Vary, si leurs valeurs peuvent être différentes de celles d'autres réponses précédentes avec les mêmes variables. Cette réponse ne doit pas contenir d'autres en-têtes d'entité si la demande utilise une validation de cache If-Range forte, et ne doit pas contenir d'autres en-têtes d'entité si la demande utilise une validation de cache If-Range faible ; cela permet d'éviter les incohérences entre le contenu de l'entité mis en cache et les informations d'en-tête d'entité mises à jour. Sinon, cette réponse DEVRAIT contenir tous les champs d'en-tête d'entité qui auraient dû être renvoyés dans la réponse 200. Si les en-têtes ETag ou Last-Modified ne correspondent pas exactement, le cache côté client doit 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 Codes d'état étendus par WebDAV(RFC 2518) Le code d'état, tel qu'il est étendu par WebDAV, 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 a une série de réponses alternatives, chacune avec sa propre adresse et des informations de négociation propres au navigateur. C'est à l'utilisateur ou au navigateur de choisir 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 cette sélection automatique doit être effectuée. Si le serveur lui-même dispose déjà d'une option de retour préférée, l'URI du retour doit être spécifié dans la valeur Location ; les navigateurs peuvent utiliser cette valeur Location comme adresse pour la redirection automatique. En outre, la 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 disposant de capacités d'édition de liens doivent automatiquement modifier l'adresse demandée pour la remplacer 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, il est interdit au navigateur de procéder à une redirection automatique, sauf confirmation de l'utilisateur, car les termes de la requête peuvent être modifiés 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 GET.
302 La ressource demandée répond maintenant temporairement à la demande à partir d'un URI différent. Cette redirection étant temporaire, le client doit continuer à envoyer ses futures requêtes à l'adresse d'origine. La 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. 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, il est interdit au navigateur de procéder à une redirection automatique, sauf confirmation de l'utilisateur, car les termes de la requête peuvent être modifiés 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 pendant 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 de remplacement de la ressource d'origine. En outre, la réponse 303 ne peut pas être mise en cache. Bien entendu, la deuxième 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 à 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 fonctionner, car la plupart des navigateurs traitent la réponse 302 exactement de la même manière que la spécification ci-dessus exige que le client traite la réponse 303.
304 Ce code d'état doit être renvoyé par le serveur si le client envoie une requête GET conditionnelle, que la requête est autorisée et que le contenu du document n'a pas changé (soit depuis la dernière visite, soit conformément aux conditions de la requête). 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 informations d'en-tête suivantes : 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 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 précédentes avec les mêmes variables. Si la demande de réponse utilise une validation de cache forte, la réponse ne doit pas contenir d'en-têtes d'entité supplémentaires ; dans le cas contraire (par exemple, une demande GET conditionnelle utilise une validation de cache faible), la réponse ne doit pas contenir d'en-têtes d'entité supplémentaires ; 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 d'un proxy spécifié. Le champ Emplacement donnera des informations sur l'URI du proxy spécifié, et le destinataire devra envoyer une demande distincte à plusieurs reprises 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 peut avoir de graves conséquences en termes de sécurité.
306 Dans la dernière version de la spécification, le code d'état 306 n'est plus utilisé.
307 Les ressources demandées répondent désormais temporairement aux demandes provenant de différents URI. Cette redirection étant temporaire, 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, il est nécessaire d'ajouter les informations ci-dessus 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, erreur sémantique, la demande actuelle ne peut pas être comprise par le serveur. Sauf modification, le client ne doit pas répéter la demande. 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 à nouveau une demande avec les informations d'en-tête Authorisation appropriées. Si la demande actuelle contient déjà des informations d'authentification, une 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à effectué au moins une tentative d'authentification, le navigateur doit montrer à 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 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 ê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 veut pas que le client obtienne d'informations.
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 le serveur 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 veut pas révéler pourquoi la demande a été rejetée ou lorsqu'il n'y a pas d'autre réponse appropriée 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 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 les prennent pas en charge ou ne les autorisent pas par défaut et renvoient 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 requête 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 d'adresses à partir de laquelle l'utilisateur ou le navigateur peut sélectionner les caractéristiques de l'entité les plus appropriées. 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 le meilleur choix en fonction du format et de ses 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 proxy DOIT renvoyer un Proxy-Authenticate pour l'interrogation de l'identité. Le client peut renvoyer un en-tête Proxy-Authorisation pour l'authentification. Voir RFC 2617.
408 Délai d'attente de la demande. Le client n'a pas terminé une demande dans le délai que le serveur était prêt à attendre. Le client peut à tout moment soumettre à nouveau la demande sans y apporter de modifications.
409 La demande n'a pas pu être traité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 souvent lors du traitement des demandes PUT. Par exemple, dans un environnement de contrôle des versions, une requête PUT soumise pour modifier une ressource particulière avec des informations de version qui entrent en conflit avec une requête précédente (d'un tiers) doit renvoyer une erreur 409 informant l'utilisateur que la requête n'a pas pu être traité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 fusionnée.
410 La ressource demandée n'est plus disponible sur le serveur et il n'y a pas d'adresse de réexpédition connue. Une telle situation doit être considérée comme permanente. Dans la mesure du 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 situation est permanente, il doit utiliser le code d'état 404. Sauf indication contraire, cette réponse peut être mise en cache. L'objectif de la réponse 410 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 à la 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 le client qu'une ressource appartenant à un individu n'est plus disponible sur le site du serveur actuel. Bien entendu, la question de savoir si toutes les ressources définitivement indisponibles doivent être marquées comme telles et combien de temps elles doivent être conservées est également importante.'410 Gone'， Il appartient au propriétaire du serveur de décider si les ressources doivent être marquées comme telles et combien de temps elles doivent être conservées.
411 Le serveur refuse d'accepter les requêtes sans que l'en-tête Content-Length soit défini. Le client peut soumettre à nouveau la demande après avoir ajouté un en-tête Content-Length valide indiquant la longueur du corps du message de la demande.
412 Le serveur n'a pas satisfait à une ou plusieurs des conditions préalables indiquées dans le champ d'en-tête de la demande lors de la validation de la demande. Ce code d'état permet au client de définir des conditions préalables dans les méta-informations 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 contient plus de données physiques qu'il ne veut ou ne peut en traiter. Dans ce cas, le serveur peut fermer la connexion pour empêcher le client de continuer à envoyer la requête. Si la situation est temporaire, le serveur doit renvoyer un en-tête Retry-After pour informer le client du temps dont il dispose pour réessayer.
414 L'URI de la requête est plus long que ce que le serveur peut interpréter, et le serveur refuse donc de servir la requête. Ce cas est rare et se produit généralement lorsque la soumission d'un 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 pour 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 demandé, ce qui peut entraîner un débordement de la mémoire tampon lorsque le paramètre GET dépasse une certaine valeur, conduisant à une 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 demandées actuellement, l'entité soumise dans la demande n'est pas dans un format supporté par le serveur et la demande est 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 coïncident pas avec les plages disponibles pour la ressource actuelle et que la requête ne définit pas d'en-tête de requête If-Range, le serveur doit renvoyer un code d'état 416. Si la plage utilise des plages d'octets, cela signifie que le 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 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 le 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 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, plus d'un utilisateur final peut être impliqué dans le décompte des connexions.
422 Le nombre de connexions entre l'adresse IP du client actuel et le serveur 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, plus d'un utilisateur final peut être impliqué dans le décompte des connexions.
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) 423 Verrouillé
424 La requête en cours a échoué en raison d'une erreur dans une requête précédente, telle que PROPPATCH. (RFC 4918 WebDAV)
425 Défini dans le projet WebDav Advanced Collections, mais ne figure 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é requise par la demande en cours. Lorsque le serveur ne reconnaît pas la méthode demandée et ne peut 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 veulent simplement refuser une connexion au client.
504 Un serveur agissant 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 pourquoi la version n'est pas prise en charge et quels sont les protocoles pris en charge par le serveur.
506 Étendue par le protocole de négociation transparente de contenu (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 transparente de contenu, 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é satisfaite. (RFC 2774)
Accès aux documents :