Petits conseils: Ctrl F Recherche rapide| Code d'état Http | Signification du code d'état |
|---|---|
| 100 | Le client doit continuer à envoyer la demande. Cette réponse temporaire est utilisée pour informer le client que certaines de ses demandes ont été reçues par le serveur et n'ont pas été rejetées. Le client doit continuer à envoyer le reste de la demande ou ignorer la réponse si la demande est terminé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 de message Upgrade d'utiliser un protocole différent pour compléter cette demande. Après avoir envoyé la dernière ligne vide de cette réponse, le serveur bascule sur les protocoles définis dans l'en-tête du message Upgrade. Des mesures similaires ne devraient être prises que lorsqu'il est plus avantageux de changer de nouveau protocole. Par exemple, passer à une nouvelle version HTTP présente un avantage par rapport à l'ancienne version, ou passer à un protocole en temps réel et synchrone pour transférer des ressources qui exploitent de telles fonctionnalités. |
| 102 | Le code d'état étendu par WebDAV(RFC 2518) signifie que le traitement sera poursuivi. |
| 200 | La demande a réussi 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é implémentée et une nouvelle ressource a été établie en fonction des besoins de la demande, et son URI a été renvoyé avec le message d'en-tête d'emplacement. Si les ressources nécessaires ne peuvent pas être établies à temps, elles doivent être renvoyées à «202 Accepted». |
| 202 | Le serveur a accepté la demande, mais ne l’a pas encore traitée. De la même manière qu’elle peut être rejetée, la demande finira peut-être par être exécutée, ou peut-être pas. Dans le cadre d’opérations asynchrones, il n’existe pas de méthode plus pratique que d’envoyer ce code d’état. Le but de la réponse renvoyant le code d’état 202 est de permettre au serveur d’accepter des requêtes relatives à d’autres processus (par exemple, une opération par lots qui n’est exécutée qu’une seule fois par jour) sans que le client ne soit obligé de maintenir la connexion avec le serveur jusqu’à ce que l’opération par lots soit entièrement terminée. Une réponse qui accepte le traitement d’une requête et renvoie le code d’état 202 doit inclure dans l’entité de la réponse des informations indiquant l’état actuel du traitement, ainsi qu’un pointeur vers un moniteur de l’état d’avancement ou vers une prévision de l’état, afin que l’utilisateur puisse estimer si l’opération a déjà été achevée. |
| 203 | Le serveur a traité la demande avec succès, mais les informations de l'en-tête d'entité renvoyées ne sont pas une collection de détermination valide sur le serveur d'origine, mais une copie locale ou tierce. Les informations actuelles peuvent être un sous-ensemble ou un super-ensemble de la version originale. Par exemple, les métadonnées contenant des ressources peuvent amener le serveur d'origine à connaître des super-informations méta-informations. L'utilisation de ce code d'état n'est pas nécessaire et ne convient que si la réponse renvoie 200 OK sans utiliser ce code d'état. |
| 204 | Le serveur a traité la demande avec succès, mais n'a pas besoin de renvoyer de contenu d'entité et souhaite renvoyer des métadonnées mises à jour. La réponse peut être sous la forme de l'en-tête d'entité, renvoyant des métadonnées nouvelles ou mises à jour. Si ces informations d'en-tête sont présentes, elles doivent faire écho à la variable demandée. Si le client est un navigateur, alors le navigateur de l'utilisateur doit conserver la page qui a envoyé la demande sans aucun changement dans la vue du document, même si les métadonnées nouvelles ou mises à jour conformément à la spécification doivent être appliquées à la vue d'activité du navigateur de l'utilisateur. La réponse 204 étant interdite d'inclure tout corps de message, elle se termine toujours par la première ligne vide derrière l'en-tête du message. |
| 205 | Le serveur a traité la demande avec succès et n'a rien renvoyé. Mais 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é l'entrée de l'utilisateur afin que l'utilisateur puisse facilement démarrer une autre entrée. Comme pour la réponse 204, cette réponse est également interdite d'inclure tout type de message et se termine par la première ligne vide derrière l'en-tête du message. |
| 206 | Le serveur a traité avec succès certaines demandes GET. Les outils de téléchargement HTTP tels que FlashGet ou Xunlei utilisent ce type de réponse pour implémenter la transmission continue de points d'arrêt ou pour décomposer un grand document en plusieurs segments de téléchargement en même temps. La demande doit contenir des informations d'en-tête Range pour indiquer la plage de contenu que le client souhaite obtenir, et peut inclure If-Range comme condition de demande. La réponse doit contenir le champ d'en-tête suivant: Content-Range est utilisé pour indiquer la plage du contenu renvoyé dans cette réponse; si Content-Type est un téléchargement multi-segments de multipart/byteranges, alors chaque segment multipart doit inclure Content-Range Le domaine est utilisé pour indiquer la plage de contenu de ce segment. Si la réponse contient Content-Length, sa valeur doit correspondre au nombre réel d'octets de la plage de contenu qu'elle renvoie. Date ETag et/ou Content-Location, si la même demande devrait renvoyer une réponse 200. Expires, Cache-Control et/ou Vary, dans la mesure où leurs valeurs peuvent différer de celles associées à d’autres réponses pour la même variable.Si cette demande de réponse utilise la validation du cache fort If-Range, alors cette réponse ne doit pas inclure d'autres en-têtes d'entité; si la demande de cette réponse utilise la vérification du cache faible If-Range, alors cette réponse interdit d'inclure d'autres en-têtes d'entité; cela évite les incohérences entre le contenu d'entité mis en cache et les informations d'en-tête d'entité mises à jour. Sinon, cette réponse doit contenir tous les domaines d'tête d'entité qui devraient être renvoyés dans la réponse 200. Si la tête ETag ou Last-Modified ne peut pas correspondre avec précision, le cache client doit interdire la combinaison du contenu renvoyé par la réponse 206 avec tout contenu précédemment mis en cache. Tout cache qui ne prend pas en charge Range et l'en-tête Content-Range interdit de mettre en cache le contenu renvoyé par la réponse 206. |
| 207 | Le code d'état étendu par WebDAV(RFC 2518) signifie que le corps de message suivant sera un message XML et peut contenir une série de codes de réponse indépendants en fonction du nombre de sous-requêtes précédentes. |
| 300 | Les ressources demandées ont une série d'informations de rétroaction parmi lesquelles choisir, chacune avec sa propre adresse spécifique et des informations de négociation pilotées par le navigateur. L'utilisateur ou le navigateur peut choisir lui-même une adresse préférée pour la redirection. Sauf s'il s'agit d'une demande HEAD, la réponse doit inclure une entité avec une liste de fonctionnalités de ressources et d'adresses, afin que l'utilisateur ou le navigateur puisse 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 réponse et des capacités du navigateur lui-même. 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 le choix de rétroaction préféré, l'URI de cette rétroaction doit être indiquée dans Location; le navigateur peut utiliser cette valeur de location comme adresse de redirection automatique. En outre, cette réponse peut également être mise en cache, sauf indication contraire. |
| 301 | La ressource demandée a été déplacée de façon permanente vers un nouvel emplacement et toute référence future à cette ressource doit utiliser l'une des URI renvoyées par cette réponse. Si possible, les clients disposant de la fonction d'édition de liens doivent modifier automatiquement l'adresse demandée en une adresse 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 domaine Location de la réponse. À moins qu'il ne s'agisse d'une demande HEAD, l'entité répondant doit inclure un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une demande GET ou HEAD, le navigateur interdit la redirection automatique à moins qu'elle ne soit confirmée par l'utilisateur, car les conditions de la demande peuvent changer. Remarque: Pour certains navigateurs qui utilisent le protocole HTTP/1.0, lorsque la demande POST qu'ils envoient reçoit une réponse 301, la demande de redirection suivante deviendra la méthode GET. |
| 302 | La ressource demandée répond désormais temporairement à la demande d'un autre URI. Une telle redirection étant temporaire, le client doit continuer à envoyer des requêtes ultérieures à 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 domaine Location de la réponse. À moins qu'il ne s'agisse d'une demande HEAD, l'entité répondant doit inclure un lien hypertexte vers le nouvel URI et une brève description. S'il ne s'agit pas d'une demande GET ou HEAD, le navigateur interdit la redirection automatique à moins qu'elle ne soit confirmée par l'utilisateur, car les conditions de la demande peuvent changer. Remarque: Bien que les spécifications RFC 1945 et RFC 2068 ne permettent pas aux clients de modifier la méthode de demande lors de la redirection, de nombreux navigateurs existants considèrent la réponse 302 comme la réponse 303 et utilisent la méthode GET pour accéder à l'URI spécifiée dans la location, ignorant la méthode d'origine demandée. Les codes d'état 303 et 307 ont été ajoutés pour clarifier le type de réaction que le serveur attend du client. |
| 303 | La réponse correspondant à la demande en cours peut être trouvée sous un autre URI, et le client doit accéder à cette ressource par une requête GET. Cette méthode existe principalement pour permettre la redirection de la sortie d’une requête POST activée par un script vers une nouvelle ressource. Cette nouvelle URI n’est pas une référence de remplacement de la ressource d’origine. Parallèlement, la réponse 303 ne doit pas être mise en cache. Bien sûr, la deuxième requête (redirection) peut être mise en cache. La nouvelle URI doit être retournée 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 hyperlien vers la nouvelle URI ainsi qu’une brève explication. Remarque: de nombreux navigateurs antérieurs à la version HTTP/1.1 ne parviennent pas à interpréter correctement le statut 303. Si l’on doit prendre en compte l’interaction avec ces navigateurs, le code d’état 302 devrait suffire, car la manière dont la plupart des navigateurs traitent une réponse 302 est précisément celle que la spécification mentionnée exige du client lorsqu’il reçoit une réponse 303. |
| 304 | Si le client a envoyé une demande GET conditionnelle et que la demande a été autorisée et que le contenu du document (depuis la dernière visite ou selon les conditions demandées) n'a pas changé, le serveur doit renvoyer ce code d'état. La réponse 304 interdit d'inclure le corps du message, elle se termine donc toujours par la première ligne vide derrière la tête du message. La réponse doit contenir les informations d'en-tête suivantes: Date, sauf si ce serveur n'a pas d'horloge. Si le serveur sans horloge respecte également ces règles, le serveur proxy et le client peuvent ajouter le champ Date à l'en-tête de réponse reçu (comme spécifié dans la RFC 2068), et le mécanisme de cache fonctionnera normalement. 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 des valeurs correspondantes d'autres réponses de la même variable précédente.Si cette demande de réponse utilise une validation de cache forte, alors cette réponse ne doit pas inclure d'autres têtes d'entité; sinon (par exemple, une demande GET conditionnelle utilise une vérification de cache faible), cette réponse est interdite d'inclure d'autres têtes d'entité; cela évite les incohérences entre le contenu d'entité mis en cache et les informations d'en-tête d'entité mises à jour. Si une réponse 304 indique que l'entité actuelle n'a pas de cache, alors le système de cache doit ignorer cette réponse et envoyer à plusieurs reprises des requêtes qui ne contiennent pas de restrictions. Si vous recevez une réponse 304 qui demande la mise à jour d'une entrée mise en cache, le système de cache doit mettre à jour l'entrée entière pour refléter la valeur de tous les champs mis à jour dans la réponse. |
| 305 | Les ressources demandées doivent être accessibles via un agent spécifié. Les informations URI sur l'agent spécifié seront données dans le domaine Location. Le destinataire doit envoyer à plusieurs reprises une demande distincte pour accéder à la ressource correspondante via l'agent. Seul le serveur d'origine peut établir la réponse 305. Remarque: Il n'y a pas de réponse explicite 305 dans RFC 2068 pour rediriger une demande distincte et ne peut être établie que par le serveur d'origine. Ignorer ces restrictions peut avoir 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 temporairement aux requêtes à partir d’un URI différent. Étant donné que ce type de redirection est temporaire, le client doit continuer à envoyer les requêtes ultérieures à l’adresse d’origine. Cette réponse n’est mise en cache que si cela est explicitement indiqué dans les en-têtes Cache-Control ou Expires. Le nouvel URI temporaire doit être retourné 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 hyperlien vers la nouvelle URI ainsi qu’une brève explication. Comme certains navigateurs ne reconnaissent pas la réponse 307, il est nécessaire d’ajouter les informations requises mentionnées ci-dessus afin que l’utilisateur puisse comprendre la situation et émettre une nouvelle demande d’accès à la nouvelle URI. Si il ne s’agit pas d’une requête GET ou HEAD, le navigateur interdit l’automatisme des redirections, sauf avec l’accord explicite de l’utilisateur, car les conditions de la requête pourraient en être modifiées. |
| 400 | 1. La sémantique est incorrecte et la demande actuelle ne peut pas être comprise par le serveur. Le client ne doit pas soumettre cette demande à plusieurs reprises, sauf modification. 2. Les paramètres de demande sont incorrects. |
| 401 | La demande actuelle nécessite une validation utilisateur. La réponse doit contenir un en-tête d'information WWW-Authenticate adapté à la ressource demandée pour demander des informations à l'utilisateur. Le client peut soumettre à plusieurs reprises une demande contenant les informations de l'en-tête Authorization appropriées. Si la demande actuelle contient déjà un certificat Authorization, la réponse 401 signifie que le serveur vérifie que ces certificats ont été refusés. Si la réponse 401 contient la même demande d'authentification que la réponse précédente et que le navigateur a essayé la vérification au moins une fois, 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 | Le code d'état est réservé pour les besoins futurs possibles. |
| 403 | Le serveur a compris la demande, mais a refusé de l’exécuter. Contrairement à la réponse 401, l’authentification ne résout rien, et cette requête ne doit pas être répétée. Si cette requête n’est pas une requête HEAD et que le serveur souhaite expliquer clairement pourquoi la requête ne peut pas être exécutée, la raison du refus doit être décrite dans le corps de la réponse. Bien entendu, le serveur peut également renvoyer une réponse 404 s’il ne souhaite pas que le client obtienne la moindre information. |
| 404 | La demande échoue et la ressource que la demande souhaite obtenir n'est pas découverte sur le serveur. Aucune information ne permet de dire à l'utilisateur si cette situation est temporaire ou permanente. Si le serveur connaît la situation, il doit utiliser le code d'état 410 pour informer l'ancienne ressource en raison de certains problèmes de mécanisme de configuration interne, qui sont indisponibles en permanence, et il n'y a pas d'adresses pouvant être transférées. Le code d'état 404 est largement utilisé lorsque le serveur ne veut pas révéler pourquoi la demande a été rejetée ou qu'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 message de tête d'Allow pour représenter une liste de méthodes de requête que la ressource actuelle peut accepter. Compte tenu du PUT, la méthode DELETE écrira sur les ressources du serveur, de sorte que la plupart des serveurs Web ne prennent pas en charge ou n'autorisent pas la méthode de demande ci-dessus dans la configuration par défaut, et une erreur 405 sera renvoyée pour de telles demandes. |
| 406 | Les caractéristiques du contenu de la ressource demandée ne satisfaisant pas les conditions spécifiées dans l’en-tête de la requête, il n’a pas été possible de générer l’entité de la réponse. À moins qu’il ne s’agisse d’une requête HEAD, la réponse doit inclure une entité contenant les caractéristiques de l’entité qui permettent à l’utilisateur ou au navigateur de choisir la variante la plus appropriée, ainsi qu’une liste d’adresses. 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, en fonction du format et de ses propres capacités, choisir lui-même la meilleure option. Cependant, la norme ne définit aucun critère permettant d’effectuer une telle sélection automatique. |
| 407 | Similaire à la réponse 401, à ceci près que le client doit s’authentifier auprès du serveur proxy. Le serveur proxy doit renvoyer un en-tête Proxy-Authenticate afin d’initier une demande d’authentification. Le client peut renvoyer un en-tête Proxy-Authorization pour procéder à l’authentification. Voir la RFC 2617. |
| 408 | Demande de délai d'attente. Le client n'a pas terminé l'envoi d'une demande dans le délai d'attente du serveur. Le client peut soumettre à nouveau cette demande à tout moment sans aucune modification. |
| 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 peut être utilisé que dans une telle situation: l'utilisateur est considéré comme capable de résoudre le conflit et soumettra à nouveau une nouvelle demande. La réponse doit contenir suffisamment d'informations pour que l'utilisateur puisse découvrir la source du conflit. Les conflits se produisent généralement dans le traitement des demandes PUT. Par exemple, dans un environnement où la vérification de version est utilisée, les informations de version jointes à une demande de modification d'une ressource spécifique soumise par PUT sont en conflit avec la demande précédente (tierce partie), puis le serveur doit renvoyer une erreur 409 à ce moment., Informer l'utilisateur que la demande ne peut pas être terminée. À ce stade, l'entité de réponse inclura très probablement une comparaison des différences entre les deux versions en conflit, afin que l'utilisateur puisse soumettre à nouveau la nouvelle version incorporée plus tard. |
| 410 | Les ressources requises ne sont plus disponibles sur le serveur et il n'y a pas d'adresse de transfert connue.. Si possible,., Alors vous devriez utiliser le code d'état 404. À l'exception des explications non importantes, la réponse peut être lente. 410, informez l'utilisateur que la ressource n'est plus disponible,. Ces types d'événements sont courants dans les services à valeur ajoutée et à durée limitée. De même, 410, les ressources appartenant à l'origine à une certaine personne ne sont plus disponibles. Bien sûr, le «410 Gone», s'il est nécessaire de conserver cette marque pendant une longue période, est entièrement utilisé par le propriétaire du serveur. |
| 411 | Le serveur a refusé d'accepter la demande sans l'en-tête Content-Length défini. Après avoir ajouté l'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, lors de la vérification des conditions préalables spécifiées dans les champs d’en-tête de la requête, n’a pas pu en satisfaire une ou plusieurs. Ce code d’état permet au client de spécifier des conditions préalables dans les métadonnées de la demande (les données des champs d’en-tête) lors de la récupération d’une ressource, afin d’éviter que cette méthode de requête ne soit appliquée à une autre ressource que celle souhaitée. |
| 413 | Le serveur refuse de traiter la demande en cours car la taille des données d'entité soumises par la demande dépasse la portée que le serveur est disposé ou peut traiter. Dans ce cas, le serveur peut fermer la connexion pour empêcher le client de continuer à envoyer cette demande. Si cette situation est temporaire, le serveur doit renvoyer un d'en-tête de réponse Retry-After pour indiquer au client combien de temps il peut réessayer. |
| 414 | La longueur de l’URI demandée dépasse la limite que le serveur peut interpréter; par conséquent, le serveur refuse de traiter cette requête. Cela est relativement rare; les cas courants incluent le fait qu’un formulaire qui devrait utiliser la méthode POST est en réalité soumis via la méthode GET, ce qui entraîne un chaînon de requête (Query String) trop long. « Trou noir » des URI de redirection: par exemple, chaque redirection incorpore l’ancienne URI comme partie de la nouvelle, ce qui entraîne, après plusieurs redirections, une URI d’une longueur excessive. Le client tente d’exploiter une vulnérabilité de sécurité présente sur certains serveurs pour attaquer ces derniers. Ce type de serveur utilise des tampons de longueur fixe pour lire ou traiter l’URI d’une requête. Lorsque le nombre de paramètres suivant le mot-clé GET dépasse une certaine valeur, un débordement de tampon peut se produire, permettant l’exécution de code arbitraire [1]. Les serveurs n’ayant pas ce type de vulnérabilité doivent renvoyer le code d’état 414. |
| 415 | Pour la méthode de la demande actuelle et la ressource demandée, l'entité soumise dans la demande n'est pas un format pris en charge dans le serveur et la demande est donc rejetée. |
| 416 | Si l'en-tête de demande Range est inclus dans la demande et que toute plage de données spécifiée dans Range ne coïncide pas avec la plage disponible de la ressource actuelle, et qu'il n'y a pas d'en-tête de demande If-Range défini dans la demande, le serveur doit renvoyer le code d'état 416. Si Range utilise une plage d'octets, cela signifie que le premier octet de toutes les plages de données spécifiées par la demande dépasse la longueur de la ressource actuelle. Le serveur doit également inclure un en-tête d'entité Content-Range tout en retournant le code d'état 416 pour indiquer la longueur de la ressource actuelle. Cette réponse est également interdite d'utiliser multipart/byteranges comme type de contenu. |
| 417 | Le contenu attendu spécifié dans l'en-tête de demande Expect ne peut pas être satisfait par le serveur, ou le serveur est un serveur proxy, et il a des preuves évidentes que le contenu d'Expect ne peut pas être satisfait sur le nœud suivant de la route actuelle. |
| 421 | Le nombre de connexions de l'adresse IP du client actuel au serveur dépasse la portée maximale de la licence du serveur. En règle générale, l'adresse IP se réfère à l'adresse du client (telle que la passerelle de l'utilisateur ou l'adresse du serveur proxy) vue depuis le serveur. Dans ce cas, le calcul du nombre de connexions peut impliquer plus d'un utilisateur final. |
| 422 | Le nombre de connexions de l'adresse IP du client actuel au serveur dépasse la portée maximale de la licence du serveur. En règle générale, l'adresse IP se réfère à l'adresse du client (telle que la passerelle de l'utilisateur ou l'adresse du serveur proxy) vue depuis le serveur. Dans ce cas, le calcul du nombre de connexions peut impliquer plus d'un utilisateur final. |
| 422 | La demande est au format correct, mais ne peut pas répondre car elle contient des erreurs sémantiques. (RFC 4918 WebDAV) La ressource actuelle 423 Locked est verrouillée. (RFC 4918 WebDAV) |
| 424 | La demande actuelle échoue, telle que PROPPATCH, en raison d'une erreur qui s'est produite dans une requête précédente. (RFC 4918 WebDAV) |
| 425 | Il est défini dans le projet de WebDav Advanced Collections, mais n'apparaît pas dans le "WebDAV Order Set Protocol" (RFC 3658). |
| 426 | Le client doit passer à TLS/1.0. (RFC 2817) |
| 449 | Extension par Microsoft, la demande représentative doit être réessayée après avoir effectué les opérations appropriées. |
| 500 | Le serveur a rencontré une situation imprévue qui l'a empêché de terminer le traitement de la demande. En général, ce problème se produit lorsque le code du programme du serveur est erroné. |
| 501 | Le serveur ne prend pas en charge une fonctionnalité requise par la demande actuelle. Lorsque le serveur ne reconnaît pas la méthode demandée et ne peut pas prendre en charge sa demande de ressources. |
| 502 | Lorsqu'un serveur travaillant comme passerelle ou proxy tente d'exécuter une demande, une réponse non valide est reçue du serveur en amont. |
| 503 | Le serveur est actuellement incapable de traiter les demandes en raison d'une maintenance temporaire ou d'une surcharge du serveur. Cette situation est temporaire et sera rétablie après un certain temps. Si le temps de retard peut être estimé, une tête de retour-After peut être incluse dans la réponse pour indiquer le temps de retard. Si cette information Retry-After n'est pas donnée, le client doit la traiter de manière à traiter la réponse 500. Remarque: La présence du code d'état 503 ne signifie pas que le serveur doit l'utiliser en cas de surcharge. Certains serveurs veulent simplement refuser la connexion du client. |
| 504 | Lorsqu'un serveur travaillant comme passerelle ou proxy tente d'exécuter une demande, il ne parvient pas à recevoir une réponse du serveur en amont (serveur identifié par URI, tel que HTTP, FTP, LDAP) ou du serveur secondaire (tel que DNS) à temps. Remarque: certains serveurs proxy renvoient des erreurs 400 ou 500 lorsque la requête DNS est en avance |
| 505 | Le serveur ne prend pas en charge ou refuse de prendre en charge la version HTTP utilisée dans la demande. Cela implique que le serveur ne peut pas ou ne veut pas utiliser la même version que le client. La réponse doit inclure une entité qui décrit pourquoi la version n'est pas prise en charge et quels protocoles le serveur prend en charge. |
| 506 | Il est étendu par le "Transparent Content Négociation Protocol" (RFC 2295), ce qui signifie qu'il y a une erreur de configuration interne sur le serveur: la ressource de variable de négociation demandée est configurée pour l'utiliser dans la négociation de contenu transparent, donc ce n'est pas un objectif approprié dans un traitement de négociation. |
| 507 | Le serveur ne peut pas stocker le contenu nécessaire pour terminer la demande. Cette situation est considérée comme temporaire. WebDAV(RFC 4918) |
| 509 | Le serveur atteint la limite de bande passante. Ce n'est pas un code de statut officiel, mais il est encore largement utilisé. |
| 510 | Les stratégies requises pour obtenir des ressources ne sont pas satisfaites. (RFC 2774) |
Liens amicaux:iCMS