| Code d'état HTTP | Signification du code de statut |
|---|
| 100 | Le côté client doit continuer à envoyer des requêtes. Cette réponse temporaire est utilisée pour informer le côté client que certains de ses requêtes ont été reçues par le serveur et n'ont pas été rejetées. Le côté client doit continuer à envoyer le reste de la requête, ou ignorer la réponse si la requête a été terminée. Le serveur doit envoyer une réponse finale au côté client après que la requête soit terminée. |
| 101 | Le serveur a compris la demande du client et informera le côté client par l'entête Upgrade pour utiliser un protocole différent pour terminer la demande. Après avoir envoyé la dernière ligne blanche dans la réponse, le serveur passera à ceux des protocoles définis dans l'entête Upgrade. Des mesures similaires ne devraient être prises que lorsque le passage à un nouveau protocole est plus bénéfique. Par exemple, passer à une nouvelle version HTTP a des avantages par rapport à une ancienne version, ou passer à un réel-protocole temps et synchrone pour délivrer des ressources qui profitent de telles fonctionnalités. |
| 102 | Le code de statut étendu par WebDAV (RFC 2518) indique que le traitement continuera. |
| 200. | La demande a réussi, et les en-têtes de réponse ou les corps de données désirés sont retournés avec la réponse. |
| 201 | La demande a été satisfaisante, et un nouveau ressource a été créé sur la base des exigences de la demande, et son URI a été retourné avec l'entête Location. Si le ressource requis ne peut pas être créé à temps, '202 Accepté' devrait être retourné. |
| 202 | Le serveur a accepté la demande, mais il ne l'a pas encore traitée. Comme il peut être rejeté, la demande peut ou peut ne pas être exécutée finalement. Dans le cas des opérations asynchrones, il n'y a pas de manière plus pratique de le faire que de renvoyer ce code de statut. Le but de retourner un 202 réponse de code de statut est de permettre au serveur d'accepter des demandes d'autres processus (tel qu'un lot-une opération basée qui n'est effectuée qu'une fois par jour) sans avoir à garder le client connecté au serveur jusqu'à ce que l'opération par lot soit terminée. En réponse à l'acceptation d'une demande de traitement et au retour d'une 202 code de statut, l'entité renvoyée doit inclure certaines informations indiquant l'état actuel du processus, ainsi qu'un pointeur vers le moniteur ou la prédiction de statut du processus, afin que l'utilisateur puisse évaluer si l'opération est terminée. |
| 203 | Le serveur a traité avec succès la demande, mais les informations méta de l'en-tête d'entité renvoyées ne constituent pas un ensemble déterministe valide sur le serveur d'origine, mais un local ou un tiers-copie de partie. Les informations actuelles peuvent être un sous-ensemble ou un sur-ensemble de la version originale. Par exemple, les métadonnées contenant des ressources peuvent permettre au serveur d'origine de connaître le méta super. L'utilisation de ce code de statut n'est pas requise et n'est appropriée que si la réponse renvoie 200 OK sans ce code de statut. |
| 204 | Le serveur a traité avec succès la demande, mais n'a pas besoin de renvoyer de contenu physique, et souhaite renvoyer des informations méta mises à jour. La réponse peut être sous forme d'en-tête d'entité, renvoyant de nouvelles ou des informations méta mises à jour. Si cette information d'en-tête existe, elle doit correspondre à la variable demandée. Si le côté client est un navigateur, alors le navigateur de l'utilisateur doit conserver la page qui a envoyé la demande sans aucune modification de la vue du document, même si les nouvelles ou les informations méta mises à jour devraient être appliquées au document dans la vue active du navigateur de l'utilisateur selon la spécification. Puisque le 204 La réponse est interdite de contenir tout corps de message, elle se termine toujours par la première ligne blanche après l'en-tête. |
| 205 | Le serveur a traité avec succès la demande et n'a rien renvoyé. Mais contrairement au 204 La réponse, la réponse qui renvoie ce code de statut 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 l'acceptation de l'entrée utilisateur afin que l'utilisateur puisse facilement commencer une autre entrée. Comme le 204 réponse, cette réponse est également interdite d'inclure tout corps de message et se termine par la première ligne blanche après l'en-tête. |
| 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 Xunlei utilisent ce type de réponse pour implémenter une continuation de point de rupture ou pour briser un grand document en plusieurs segments de téléchargement pour télécharger simultanément. La requête doit contenir un en-tête Range pour indiquer la plage de contenu que le client souhaite, et peut inclure If-Range comme condition de requête. La réponse doit contenir les en-têtes de champ suivants : Content-Range pour indiquer la plage de contenu retourné dans cette réponse ; si c'est un multi-téléchargement de segment avec Content-Type multipart/byteranges, chaque segment de plusieurs parties devrait contenir un Content-l'en-tête Range pour indiquer la plage de contenu de ce segment. Si la réponse contient Content-Length, alors sa valeur doit correspondre au nombre réel d'octets dans la plage de contenu qu'elle retourne. Date ETag et/ou Content-Location, si la même demande devrait renvoyer une 2réponse 00. Expires, Cache-Contrôle, et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses au même variable avant. Si cette réponse utilise If-validation de cache fort pour Range, alors cette réponse ne devrait pas inclure d'autres en-têtes d'entité ; si cette réponse utilise If-validation de cache faible pour Range, alors cette réponse ne devrait pas inclure d'autres en-têtes d'entité ; cela évite les incohérences entre le contenu de l'entité stocké et les informations d'en-tête de l'entité mises à jour. Sinon, cette réponse devrait contenir tous les champs d'en-tête d'entité qui devraient être retournés dans une 2réponse 00. Si l'ETag ou le Last-en-têtes Modified ne correspondent pas exactement, le cache côté client devrait interdire la combinaison du contenu retourné dans la 206 réponse avec tout contenu stocké précédemment. Toute cache qui ne prend pas en charge Range et les-L'en-tête Range est interdit de stocker le contenu retourné par la 206 réponse. |
| 207 | Un code d'état étendu par WebDAV (RFC 2518) représente que le corps du 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-réseaux précédents-requêtes. |
| 300 | La ressource demandée a une gamme d'options de feedback, chacune avec son propre adresse spécifique et navigateur-permet à l'utilisateur ou au navigateur de choisir une adresse préférée pour la redirection. Sauf si c'est une requête HEAD, la réponse doit inclure une entité avec une liste d'attributs de ressource et d'adresses à partir desquelles 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 des capacités du navigateur. Bien sûr, l'information de négociation dérivée par RFC 2616 ne spécifie pas comment cette sélection automatique doit être effectuée. Si le serveur lui-même a déjà une sélection de feedback préférée, l'URI du feedback doit être spécifié dans le champ Location ; les navigateurs peuvent utiliser cette valeur de Location comme adresse pour la redirection automatique. De plus, sauf indication contraire, la réponse est également stockable en cache. |
| 301 | La ressource demandée a été déplacée de manière permanente vers un nouveau lieu, et toute future référence à cette ressource doit utiliser l'une des plusieurs URI renvoyées par cette réponse. Si possible, le côté client avec des capacités d'édition de lien doit automatiquement changer l'adresse demandée en celle renvoyée par le serveur. Sauf indication contraire, cette réponse est également stockable en cache. L'URI permanent nouveau doit être renvoyé dans le champ Location de la réponse. Sauf si c'est une requête HEAD, l'entité de réponse doit contenir un hyperlien vers le nouveau URI et une brève description. Si ce n'est pas une requête GET ou HEAD, le navigateur est interdit de rediriger automatiquement sauf confirmation par l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Note : Pour certains navigateurs utilisant la spécification HTTP/1.0 protocole, lorsqu'ils envoient une requête POST et obtiennent un 301 réponse, la requête de redirection suivante sera GET. |
| 302 | La ressource demandée répond maintenant temporairement à la requête à partir d'une autre URI. Comme ces redirections sont temporaires, le côté client doit continuer à envoyer des requêtes futures à l'adresse originale. Cette réponse peut être mise en cache uniquement si spécifié dans Cache-Contrôle ou Expires. La nouvelle URI temporaire doit être retournée dans le champ Location de la réponse. Sauf si c'est une requête HEAD, l'entité de réponse doit contenir un hyperlien vers la nouvelle URI et une brève description. Si ce n'est pas une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf confirmation par l'utilisateur, car les conditions de la requête peuvent changer en conséquence. Note : Bien que l'RFC 1945 et RFC 2068 spécifications ne permettent pas au côté client de changer la méthode de la requête lors d'une redirection, de nombreux navigateurs existants traitent les 302 réponse en tant que 303 réponse et utiliser GET pour accéder à l'URI spécifié dans l'entête Location, en ignorer la méthode de requête originale. Les codes de statut 303 et 307 ont été ajoutés pour clarifier ce que le serveur s'attend du côté client. |
| 303 | la réponse à la requête actuelle peut être trouvée sur une autre URI, et le côté client doit obtenir l'accès à cette ressource. Cette méthode existe principalement pour permettre aux scripts-redirige la sortie de la requête POST activée vers une nouvelle ressource. Cette nouvelle URI n'est pas une référence de remplacement à la ressource originale. De plus, 303 les réponses sont interdites d'être mises en cache. Bien sûr, une deuxième demande (redirection) peut être mise en cache. Le nouveau URI doit être renvoyé dans le champ Location de la réponse. Sauf si c'est une demande HEAD, l'entité de réponse doit contenir un hyperlien vers le nouveau URI et une brève description. Note : De nombreux navigateurs avant HTTP/1.1 ne comprend pas 303 correctement. Si vous devez prendre en compte l'interaction avec ces navigateurs, le 302 le code de statut devrait être suffisant, car la plupart des navigateurs gèrent 302 réponses de la même manière que le spécifie le client ci-dessus 303 réponses. |
| 304 | Si le côté client envoie une demande GET conditionnelle et que la demande a été autorisée, et que le contenu du document n'a pas changé (depuis la dernière visite ou selon les conditions de la demande), le serveur doit renvoyer ce code de statut. 304 les réponses sont interdites d'inclure des corps de messages, donc elles doivent toujours se terminer par la première ligne blanche après l'en-tête. La réponse doit contenir les informations d'en-tête suivantes : Date, à moins que ce serveur n'ait pas d'horloge.
Si le serveur sans horloge suit également ces règles, alors le serveur proxy et le côté client peuvent ajouter le champ Date à l'en-tête de réponse reçue par eux-mêmes (comme spécifié dans RFC 2068), et le mécanisme de cache fonctionnera correctement. ETag et/ou Content-Location, si la même demande devrait renvoyer une 2réponse 00. Expires, Cache-Contrôle, et/ou Vary, si sa valeur peut être différente de la valeur correspondante aux autres réponses à la même variable avant.
Si cette demande de réponse utilise une validation de cache forte, alors cette réponse ne devrait pas inclure d'autres en-têtes d'entité ; sinon (par exemple, une demande GET conditionnelle utilise une validation de cache faible), cette réponse est interdite d'inclure d'autres en-têtes d'entité ; cela évite les incohérences entre le contenu de l'entité en cache et les informations d'en-tête de l'entité mises à jour. Si un 304 réponse indique qu'une entité n'est pas actuellement en cache, le système de cache doit ignorer la réponse et envoyer des requêtes répétées sans restriction.
Si une 304 réponse reçue pour mettre à jour une entrée de cache, le système de cache doit mettre à jour l'entrée entière 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 accédée via le proxy spécifié. Les informations URI du proxy spécifié sont données dans le champ Location. Le destinataire doit envoyer des requêtes séparées à répétition pour accéder à la ressource correspondante via ce proxy. Seul le serveur d'origine peut établir un 305 réponse. Note : Il n'y a pas de spécification explicite 305 réponse dans RFC 2068 pour rediriger une seule requête, et cela ne peut être établi que par le serveur d'origine. Ignorer ces restrictions peut entraîner des conséquences de sécurité graves. |
| 306 | Dans la dernière version de la spécification, la 306 le code de statut n'est plus utilisé. |
| 307 | La ressource demandée répond temporairement à la requête à partir d'un autre URI. Comme ces redirections sont temporaires, le côté client doit continuer à envoyer des requêtes futures à l'adresse originale. Cette réponse ne peut être mise en cache que si spécifié dans Cache-Contrôle ou Expires. Le nouveau URI temporaire doit être retourné dans le champ Location de la réponse. Sauf si c'est une requête HEAD, l'entité répondante doit contenir un hyperlien pointant vers le nouveau URI et une brève description. Comme certains navigateurs ne reconnaissent pas les 307 réponse, il faut ajouter les informations ci-dessus afin que l'utilisateur puisse comprendre et demander l'accès au nouveau URI.
Si cette requête n'est pas une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf confirmation par 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. Sauf modification, le client-side ne devrait pas soumettre la requête plusieurs fois. 2. Les paramètres de la requête sont incorrects. |
| 401 | La requête actuelle nécessite l'authentification de l'utilisateur. La réponse doit contenir un WWW-en-tête d'authentification pour la ressource demandée pour demander à l'utilisateur des informations. Le client-side peut soumettre une nouvelle requête avec les informations appropriées d'en-tête d'autorisation. Si la requête actuelle contient déjà des certificats d'autorisation, alors le 401 réponse représente que le serveur a rejeté ces certificats. Si le 401 réponse contient la même requête d'authentification que la réponse précédente, et le navigateur a tenté l'authentification au moins une fois, alors le navigateur devrait montrer à l'utilisateur les informations d'entité contenues dans la réponse, car cette information d'entité peut contenir des informations diagnostiques pertinentes. Voir RFC 2617. |
| 402 | Ce code de statut est réservé pour des besoins futurs possibles. |
| 403 | Le serveur a compris la requête, mais a refusé de l'exécuter. Contrairement à un 401 réponse, l'authentification n'aide pas, et la requête ne doit pas être répétée. Si ce n'est pas une requête HEAD, et le serveur veut être en mesure d'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 sûr, le serveur peut également retourner un 404 réponse si il ne veut pas que le client-side obtienne aucune information. |
| 404 | La requête a échoué, et la ressource souhaitée n'a pas été trouvée sur le serveur. Il n'y a aucune information pour informer l'utilisateur si la condition est temporaire ou permanente. Si le serveur est au courant de la situation, the 410 Le code de statut doit être utilisé pour informer l'ancienne ressource qu'elle est définitivement indisponible en raison d'un mécanisme de configuration interne et n'a pas d'adresse à laquelle sauter. The 404 Le code de statut est largement utilisé lorsque le serveur ne veut pas révéler pourquoi la requête 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 un en-tête Allow indiquant une liste de méthodes de requête que la ressource actuelle peut accepter. Comme les méthodes PUT et DELETE écrivent des ressources sur le serveur, la plupart des serveurs web ne supportent pas ou ne permettent pas par défaut les méthodes de requête ci-dessus, et renverront un 405 erreur pour de telles requêtes. |
| 406 | Les caractéristiques du contenu de la ressource demandée ne correspondent pas aux conditions de l'en-tête de la requête, donc une entité de réponse ne peut pas être générée. Sauf si c'est une requête HEAD, la réponse doit renvoyer une entité qui permet à l'utilisateur ou au navigateur de sélectionner les caractéristiques d'entité les plus appropriées et la liste des adresses. Le format de l'entité est déterminé par le type de média défini dans le Content-En-tête de type. Le navigateur peut faire le meilleur choix en fonction du format et de ses propres capacités. Cependant, la spécification ne définit aucune critère pour faire de telles sélections automatiques. |
| 407 | Similaire à la 401 , sauf que le client doit s'authentifier sur le serveur Proxy. Le serveur Proxy doit renvoyer une réponse Proxy-Authentification pour l'authentification. Le client peut renvoyer une réponse Proxy-En-tête d'autorisation pour l'authentification. Voir RFC 2617. |
| 408 | Le temps d'attente de la requête a expiré. Le client n'a pas terminé l'envoi de la requête dans le temps où le serveur était prêt à attendre. Le client peut soumettre à nouveau la requête à tout moment sans aucune modification. |
| 409 | La requête 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 si on suppose que l'utilisateur peut résoudre le conflit et soumettre une nouvelle requête. 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 pendant le traitement des requêtes PUT. Par exemple, dans une version-environnement vérifié, si les informations de version attachées à un PUT-demande de modification soumise pour une ressource particulière conflictue avec une précédente (troisième-partie) demande, le serveur doit renvoyer un 409 erreur informant l'utilisateur que la demande n'a pas pu être complétée.
À ce moment, l'entité de réponse est susceptible de contenir une comparaison des différences entre les deux versions conflictuelles, afin que l'utilisateur puisse soumettre à nouveau la version fusionnée. |
| 410 | La ressource demandée n'est plus disponible sur le serveur et n'a aucune adresse de redirection connue. Cette condition doit être considérée comme permanente. Si possible, le côté client avec la capacité de modifier les liens doit 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 condition est permanente, alors un 404 doit être utilisé. Sauf indication contraire, cette réponse est susceptible d'être mise en cache. Le but de la 410 La réponse est principalement utilisée pour aider l'administrateur du site web à maintenir le site, à informer l'utilisateur que la ressource n'est plus disponible, et que l'exploitant du serveur souhaite que toutes les connexions distantes à cette ressource soient supprimées.
Ce type d'événement est courant dans le temps-valeur limitée-services ajoutés. De même, le 410 La réponse est utilisée pour informer le côté client que les ressources appartenant initialement à un individu ne sont plus disponibles sur le site serveur actuel. Bien sûr, cela dépend entirely de l'exploitant du serveur de décider de marquer toutes les ressources définitivement indisponibles comme' 410 Disparu ', et pendant combien de temps conserver ce marqueur. |
| 411 | Le serveur refuse de recevoir la requête sans définir un contenu-En-tête de longueur. Après avoir ajouté un contenu valide-En-tête de longueur indiquant la longueur du corps de la requête, le côté client peut soumettre la requête à nouveau. |
| 412 | Le serveur a échoué à répondre à une ou plusieurs des préalables lors de la vérification qu'ils étaient donnés dans le champ d'en-tête de la requête. Ce code de statut permet au côté client de définir des préalables dans les métadonnées demandées (données du champ d'en-tête de la requête) lors de la récupération de ressources, thereby preventing the request method from being applied to resources other than what it wants. |
| 413 | Le serveur refuse de traiter la requête actuelle parce que la requête soumet plus de données d'entité que le serveur est prêt ou capable de gérer. Dans ce cas, le serveur peut fermer la connexion pour empêcher le côté client de continuer à envoyer la requête. Si cette situation est temporaire, le serveur doit renvoyer un Retry-Après l'en-tête de réponse pour informer le côté client de combien de temps il peut réessayer. |
| 414 | L'URI demandé est plus long que ce que le serveur peut interpréter, donc le serveur refuse de traiter la requête. Cela est rare, et les cas courants incluent : Un soumission de formulaire qui devrait avoir utilisé la méthode POST devient une méthode GET, causant la chaîne de requête (Query String) d'être trop longue. URI de redirection " trous noirs ", tels que chaque redirection utilisant l'URI ancien comme partie de l'URI nouveau, entraînant l'URI devenant trop longue après plusieurs redirections. Le client tente d'attaquer le serveur avec des bugs de sécurité existants dans certains serveurs.
Ce type de serveur utilise un-bloc de longueur pour lire ou manipuler l'URI demandé. Lorsque les paramètres après GET dépassent une certaine valeur, un débordement de pile peut se produire, entraînant l'exécution de code arbitraire [1]. Les serveurs sans telles vulnérabilités doivent renvoyer un 414 code de statut. |
| 415 | Pour la méthode de la requête actuelle et le resource demandé, l'entité soumise dans la requête n'est pas dans un format pris en charge par le serveur, donc la requête est rejetée. |
| 416 | Si la requête contient un en-tête de plage et que les plages de données spécifiées dans la plage ne coïncident pas avec la plage disponible du resource actuel, et que l'If-L'en-tête de plage n'est pas défini dans la requête, le serveur doit renvoyer un 416 code d'état. Si l'Range utilise un intervalle de bytes, alors cette situation signifie que la première position de byte de tous les intervalles de données spécifiés par la requête dépasse la longueur de la ressource actuelle. Le serveur doit également inclure un Content-l'en-tête d'entité Range avec le 416 code d'état pour indiquer la longueur de la ressource actuelle. Cette réponse est également interdite d'utiliser multipart/byteranges en tant que son Contenu-Type. |
| 417 | Le contenu attendu spécifié dans l'en-tête de requête Expect ne peut pas être satisfait par le serveur, ou le serveur est un serveur proxy qui a des preuves claires que le contenu attendu ne peut pas être satisfait sur le prochain noeud du chemin actuel. |
| 421 | Le nombre de connexions au serveur à partir de l'adresse de protocole Internet où se trouve le côté client actuel dépasse le maximum autorisé par le serveur. Habituellement, l'adresse de protocole Internet ici fait référence à l'adresse du côté client vue du serveur (comme l'adresse de passerelle ou de proxy du utilisateur). Dans ce cas, le comptage des connexions peut impliquer plus d'un utilisateur final. |
| 422 | Le nombre de connexions au serveur à partir de l'adresse de protocole Internet où se trouve le côté client actuel dépasse le maximum autorisé par le serveur. Habituellement, l'adresse de protocole Internet ici fait référence à l'adresse du côté client vue du serveur (comme l'adresse de passerelle ou de proxy du utilisateur). Dans ce cas, le comptage des connexions peut impliquer plus d'un utilisateur final. |
| 422 | La requête a été formatée correctement, mais n'a pas pu être répondue en raison d'une erreur sémantique. (RFC 4918 WebDAV) 423 Verrouillé La ressource actuelle est verrouillée. (RFC 4918 WebDAV) |
| 424 | La requête actuelle a échouée en raison d'une erreur dans une requête précédente, telle que PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Défini dans le projet de collections avancées WebDav, mais pas dans le protocole séquentiel WebDAV (RFC 3658). |
| 426 | Le côté client doit passer à TLS/1.0. (RFC 2817) |
| 449 | Étendu par Microsoft, les requêtes doivent être réessayées après avoir effectué l'action appropriée. |
| 500 | Le serveur a rencontré une situation inattendue qui l'a empêché de compléter la requête. Généralement, ce problème se produit lorsque le code du serveur échoue. |
| 501 | Le serveur ne prend pas en charge une fonction requise par la requête actuelle. Lorsque le serveur ne peut pas reconnaître la méthode demandée et ne peut pas prendre en charge sa demande pour toute ressource. |
| 502 | Lorsqu'un serveur fonctionnant en tant que passerelle ou proxy tente d'exécuter une requête, il reçoit une réponse invalide d'un serveur en amont. |
| 503 | Le serveur est actuellement incapable de traiter les requêtes en raison de la maintenance temporaire du serveur ou de la surcharge. Cette condition est temporaire et sera restaurée après un certain temps. Si le temps de délai peut être prédit, la réponse peut inclure un Retry-Après l'en-tête pour indiquer le temps de délai. Si ce Retry-Après que les informations ne sont pas fournies, le côté client doit les traiter comme s'il s'agissait d'un 5réponse 00. Note : L'existence d'un 503 code d'état ne signifie pas que le serveur doit l'utiliser en cas de surcharge. Certains serveurs souhaitent simplement refuser la connexion du client. |
| 504 | Lorsque un serveur travaillant en tant que passerelle ou proxy essaie d'exécuter une requête, il échoue à recevoir une réponse d'un serveur en amont (identifié par l'URI, tel que HTTP, FTP, LDAP) ou d'un serveur secondaire (tel que DNS) en temps utile. Note : Certains serveurs proxy renvoient un 400 ou 5Erreur 00 lorsque la requête DNS expire |
| 505 | Le serveur ne prend pas en charge, ou refuse de prendre en charge, la version de HTTP utilisée dans la requête. Cela implique que le serveur ne peut pas ou ne voudra pas utiliser la même version que le côté client. La réponse doit inclure 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 Transparente (RFC 2295), cela représente une erreur de configuration interne sur le serveur : la variable de négociation de ressource demandée est configurée pour utiliser elle-même dans une négociation de contenu transparente, et donc n'est pas un point de concentration approprié dans un processus de négociation. |
| 507 | Le serveur ne peut pas stocker le contenu nécessaire pour compléter la requête. Cette condition est considérée comme temporaire. WebDAV (RFC 4918) |
| 509 | Le serveur a atteint la limite de bande passante. Ce n'est pas un code d'état officiel, mais il est toujours largement utilisé. |
| 510 | Les politiques requises pour obtenir des ressources ne sont pas satisfaites. (RFC 2774) |
