Boîte à outils iToolify
Code d'état HttpSignification du code d'état
100Le 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.
101Le 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.
102Le code d'état étendu par WebDAV(RFC 2518) signifie que le traitement sera poursuivi.
200La 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.
201La 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».
202Le serveur a accepté la demande mais ne l'a pas encore traitée. Tout comme elle peut être rejetée, la demande finale peut ou non être exécutée. 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 de la réponse qui renvoie le code d'état 202 est de permettre au serveur d'accepter les demandes d'autres processus (par exemple, une opération basée sur le traitement par lots qui n'est exécutée qu'une fois par jour) sans que le client reste connecté au serveur jusqu'à ce que l'opération de traitement par lots soit terminée. La réponse qui accepte le traitement de la demande et renvoie le code d'état 202 doit inclure des informations indiquant l'état actuel de traitement dans l'entité renvoyée, ainsi qu'un pointeur vers le moniteur d'état de traitement ou la prédiction d'état, afin que l'utilisateur puisse estimer si l'opération a été terminée.
203Le 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.
204Le 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.
205Le 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.
206Le 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, 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 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.
207Le 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.
300Les 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.
301La 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.
302La 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.
303La réponse correspondant à 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 à la sortie de demande POST activée par le script de rediriger vers une nouvelle ressource. Ce nouvel URI n'est pas une référence alternative à la ressource d'origine. Dans le même temps, la réponse 303 est interdite d'être mise en cache. Bien sûr, la deuxième demande (redirection) peut être mise en cache. Le nouvel URI 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. Remarque: De nombreux navigateurs précédents de la version HTTP/1.1 ne comprenaient pas correctement l'état 303. Si vous devez considérer l'interaction avec ces navigateurs, le code d'état 302 doit être compétent, car la plupart des navigateurs traitent la réponse 302 précisément ce que la spécification ci-dessus exige que le client traite la réponse 303.
304Si 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.
305Les 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é.
306Dans la dernière version de la spécification, le code d'état 306 n'est plus utilisé.
307La 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. Étant donné que certains navigateurs ne peuvent pas reconnaître la réponse 307, il est nécessaire d'ajouter les informations nécessaires ci-dessus afin que l'utilisateur puisse comprendre et envoyer une demande d'accès au nouvel URI. 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.
4001. 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.
401La 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.
402Le code d'état est réservé pour les besoins futurs possibles.
403Le serveur a compris la demande, mais refuse de l'exécuter. Contrairement à la réponse 401, l'authentification ne fournit aucune aide et cette demande ne doit pas être répétée. Si ce n'est pas une demande HEAD et que le serveur souhaite expliquer clairement pourquoi la demande 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 obaisse des informations.
404La 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.
405La 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.
406Les 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.
407Semblable à la réponse 401, sauf que le client doit s'authentifier sur le serveur proxy. Le serveur proxy doit renvoyer un Proxy-Authenticate pour l'interrogatoire d'identité. Le client peut renvoyer un en-tête d'information Proxy-Authorization pour la vérification. Voir RFC 2617.
408Demande 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.
409La 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.
410Les 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.
411Le 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.
412Lorsque le serveur vérifie qu'une ou plusieurs des conditions préalables sont données dans le champ-tête de la demande, il ne satisfait pas. Ce code d'état permet au client de définir des conditions préalables dans les métadonnées demandées (données de champ d'en-tête de demande) lors de l'acquisition de ressources, afin d'éviter que la méthode de requête ne soit appliquée à des ressources autres que le contenu souhaité.
413Le 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.
414La 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.
415Pour 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.
416Si 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.
417Le 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.
421Le 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.
422Le 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.
422La 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)
424La 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)
425Il est défini dans le projet de WebDav Advanced Collections, mais n'apparaît pas dans le "WebDAV Order Set Protocol" (RFC 3658).
426Le client doit passer à TLS/1.0. (RFC 2817)
449Extension par Microsoft, la demande représentative doit être réessayée après avoir effectué les opérations appropriées.
500Le 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é.
501Le 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.
502Lorsqu'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.
503Le 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.
504Lorsqu'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
505Le 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.
506Il 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.
507Le serveur ne peut pas stocker le contenu nécessaire pour terminer la demande. Cette situation est considérée comme temporaire. WebDAV(RFC 4918)
509Le serveur atteint la limite de bande passante. Ce n'est pas un code de statut officiel, mais il est encore largement utilisé.
510Les stratégies requises pour obtenir des ressources ne sont pas satisfaites. (RFC 2774)
Votre empreinte:

Boîte à outils iToolifyNavigation

Liens amicaux:iCMS