Résumé du code d'état HTTP

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

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!