Le tableau de classification des codes d'état http le plus complet et le plus détaillé est ici !

                                                                                                           

Classification du code d'état HTTP

Catégorie	Description de la catégorie
1**	Information, le serveur a reçu la demande et le demandeur doit continuer à effectuer l'opération
2**	Succès, l'opération a été reçue et traitée avec succès
3**	Redirection, une action supplémentaire est requise pour terminer la demande
4**	Erreur client, la demande contenait une syntaxe erreur ou la demande n'a pas pu être complétée
5**	Erreur du serveur, une erreur s'est produite pendant que le serveur traitait la demande

Tableau des codes d'état HTTP (version 1) Ce tableau contient le nom anglais du code d'état

. La ressource demandée peut inclure plusieurs emplacements, et par conséquent, une liste de caractéristiques et d'adresses de ressources peut être renvoyée pour que le terminal utilisateur (par exemple : navigateur) sélectionne Déplacé de manière permanente. La ressource demandée a été définitivement déplacée vers le nouvel URI, les informations renvoyées incluront le nouvel URI et le navigateur sera automatiquement dirigé vers le nouvel URI. Toute nouvelle demande à venir doit utiliser le nouvel URI au lieu de Déplacement temporaire. Similaire au 301. Mais la ressource n'est déplacée que temporairement. Le client doit continuer à utiliser l'URI d'origine pour afficher d'autres adresses. Similaire au 301. Utilisez les requêtes GET et POST pour afficher Non modifié. La ressource demandée n'a pas été modifiée. Lorsque le serveur renvoie ce code d'état, aucune ressource ne sera renvoyée. Les clients mettront généralement en cache les ressources accessibles en fournissant un en-tête indiquant que le client souhaite renvoyer uniquement les ressources modifiées après une date spécifiée Utiliser le proxy. La ressource demandée doit être accessible via un proxy Le code d'état HTTP obsolète Redirection temporaire. Similaire au 302. Utilisez la redirection de demande GET

Code d'état	Nom anglais du code d'état	Description en chinois
Codes d'état commençant par 1
100	Continuer	Continuer. Le client doit poursuivre sa demande
101	Switching Protocols	protocoles de commutation. Le serveur change de protocole en fonction de la demande du client. Vous ne pouvez passer qu'à un protocole plus avancé, par exemple passer à une nouvelle version du protocole HTTP
2 Le code d'état commençant par
200	OK	est réussi. . Généralement utilisé pour les requêtes GET et POST
201	Created	a été créé. Demande et création réussie d'une nouvelle ressource
202	Accepté	Accepté. La demande a été acceptée, mais le traitement n'est pas terminé
203	Informations non autorisées	Informations non autorisées. La demande a abouti. Mais les méta-informations renvoyées ne sont pas sur le serveur d'origine, mais une copie
204	Pas de contenu	Pas de contenu. Le serveur a traité avec succès, mais aucun contenu n'a été renvoyé. Garantit que le navigateur continue d'afficher le document actuel sans mettre à jour la page Web
205	Réinitialiser le contenu	Réinitialiser le contenu. Le traitement du serveur réussit et le terminal utilisateur (par exemple le navigateur) doit réinitialiser la vue du document. Ce code retour peut être utilisé pour effacer le champ de formulaire du navigateur
206	Contenu partiel	. Le serveur a traité avec succès une partie de la requête GET
Code d'état commençant par 3
300	Choix multiples	Choix multiples
	301	Déplacé de façon permanente
	302	Found
	303	Voir Autre
	304	Non modifié
	305	Utiliser le proxy
	306	Unused
	307	Redirection temporaire
	code d'état commençant par 4	🎜🎜
400	Bad Request	La demande du client contient une erreur de syntaxe et le serveur ne peut pas la comprendre
401	Non autorisé	La demande nécessite une authentification de l'utilisateur
402	Payer ment requis	Réservé, Pour une utilisation future
403	Interdit	Le serveur a compris la requête du client, mais a refusé d'exécuter la requête
404	Non trouvé	Le serveur n'a pas pu trouver la ressource ( page Web) en fonction de la demande du client. Grâce à ce code, les concepteurs de sites Web peuvent créer une page personnalisée "La ressource que vous avez demandée est introuvable"
405	Méthode non autorisée	La méthode dans la demande du client est interdite
406	Non acceptable	Le serveur ne peut pas terminer la demande en fonction des caractéristiques de contenu demandées par le client
407	Authentification proxy requise	La demande nécessite une authentification proxy, similaire à 401, mais le demandeur doit utiliser le proxy pour l'autorisation
408	Request Time-out	Le serveur a attendu trop longtemps la requête envoyée par le client, a expiré
409	Conflit	Le serveur peut renvoyer ce code lors de la réalisation de la requête PUT du client, et un conflit s'est produit lorsque le serveur a traité la requête
410	Gone	La ressource demandée par le client n'existe plus. 410 est différent de 404. Si la ressource a été définitivement supprimée, le code 410 peut être utilisé. Le concepteur du site Web peut spécifier le nouvel emplacement de la ressource via le code 301
411	Longueur requise	Le serveur. ne peut pas gérer la demande incorrecte envoyée par le client. Demande d'informations avec Content-Length
412	Échec de la précondition	Erreur de précondition pour les informations de demande du client
413	Entité de demande trop grande	Parce que l'entité demandée est trop volumineux, le serveur ne peut pas le traiter. La demande est donc refusée. Pour empêcher les demandes continues du client, le serveur peut fermer la connexion. Si le serveur ne peut pas le traiter temporairement, il contiendra un message de réponse Retry-After
414	Request-URI Too Large	L'URI demandé est trop long (l'URI est généralement une URL) et le le serveur ne peut pas le traiter
415	Type de média non pris en charge	Le serveur ne peut pas gérer le format de média attaché à la demande
416	Plage demandée non satisfiable	La plage demandée par le client n'est pas valide
417	Échec de l'attente	Le serveur ne peut pas répondre à l'attente Les informations d'en-tête de la demande
code d'état commençant par 5
500	Serveur interne Erreur	Le serveur a un interne erreur et ne peut pas terminer la demande
501	Non implémenté	Serveur La fonctionnalité demandée n'est pas prise en charge et la demande ne peut pas être complétée
502	Bad Gateway	Le serveur agissant comme passerelle ou proxy a reçu une demande invalide du serveur distant
503	Service indisponible	En raison d'une surcharge Ou en raison de la maintenance du système, le serveur est temporairement incapable de traiter la demande du client. La durée du délai peut être incluse dans les informations d'en-tête Retry-After du serveur
504	Gateway Time-out	Le serveur agissant en tant que passerelle ou proxy n'a pas obtenu la demande du serveur distant à temps
505	Version HTTP non prise en charge	Le serveur ne prend pas en charge la version du protocole HTTP demandée et ne peut pas terminer le traitement

Liste des codes d'état HTTP (version 2) La description de ce tableau est plus détaillée

Tutoriel vidéo PHP"

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 un protocole différent pour compléter la demande. Après avoir envoyé la dernière ligne vierge 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	Un code d'état étendu par WebDAV (RFC 2518), indiquant que le traitement va se poursuivre.
200	La requête a réussi et l'en-tête de réponse ou le corps de données attendu par la requête sera renvoyé avec cette réponse.
201	La demande a été satisfaite et une nouvelle ressource a été créée en fonction des besoins de la demande, et son URI a été renvoyée avec les informations d'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 ne l'a pas encore traitée. 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, mais les métainformations d'en-tête d'entité renvoyées ne sont pas un ensemble déterminé valide sur le serveur d'origine, mais une copie provenant d'un local ou d'un 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 n'a pas besoin de renvoyer le contenu de l'entité et espère renvoyer des méta-informations mises à jour. 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 la requête 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 inclure les champs d'en-tête suivants : Content-Range est utilisé pour indiquer la plage de contenu renvoyée dans cette réponse ; s'il s'agit d'un téléchargement en plusieurs parties avec Content-Type multipart/byteranges, chaque partie en plusieurs parties doit contenir Content-Range. domain est utilisé pour indiquer la portée du contenu de ce paragraphe. 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 du cache fort If-Range, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité ; si cette demande de réponse utilise la vérification du cache faible If-Range, alors il est interdit à cette réponse de contenir d'autres en-têtes d'entité ; contenu de l'entité mis en cache et 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	Le code d'état étendu par WebDAV (RFC 2518) 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 propose une gamme de réponses alternatives, chacune avec sa propre adresse spécifique et ses propres informations de négociation du pilote de 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 un 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 permanent doit être renvoyé dans le champ Emplacement de la réponse. Sauf s'il s'agit d'une requête HEAD, l'entité de 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 utilisant 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 demandes 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 requête 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 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 une requête GET conditionnelle et que la requête est autorisée, mais que le contenu du document n'a pas changé (depuis le dernier accès ou selon les conditions de la requête), le serveur DEVRAIT renvoyer ceci code d'état. 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 accessible via le proxy spécifié. Les informations URI du proxy spécifié seront indiquées dans le champ Emplacement. 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 demandes 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 reconnaissent pas la réponse 307, les informations nécessaires ci-dessus doivent être ajoutées afin que les utilisateurs puissent comprendre et faire des demandes d'accès au nouvel URI. S'il ne s'agit pas d'une requête GET ou HEAD, le navigateur interdit la redirection automatique sauf confirmation de l'utilisateur, car les conditions de la requête peuvent changer en conséquence.
400	1. La sémantique est incorrecte et la requête actuelle 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 demande actuelle nécessite une vérification 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 la RFC2617.
402	Ce code de statut est réservé à d'éventuels besoins futurs.
403	Le serveur a compris la requête, mais a refusé de l'exécuter. Contrairement à une réponse 401, l’authentification n’apporte aucune aide et la demande ne doit pas être soumise à nouveau. S'il ne s'agit pas d'une requête HEAD et que le serveur souhaite pouvoir expliquer pourquoi la requête ne peut 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 requête a échoué. La ressource demandée n'a pas été trouvée 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 ligne de requête ne peut pas être utilisée 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	Les caractéristiques de contenu de la ressource demandée ne peuvent pas satisfaire aux conditions de l'en-tête de la requête, 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	est 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	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 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 n'est plus disponible sur le serveur et n'a aucune adresse de redirection 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 entendu, c'est au propriétaire du serveur de décider si toutes les ressources indisponibles en permanence doivent être marquées comme « 410 Gone » et combien de temps elles doivent conserver cette marque.
411	Le serveur a refusé d'accepter la demande sans définir l'en-tête Content-Length. Après avoir ajouté un en-tête Content-Length valide indiquant la longueur du corps du message de la demande, le client peut soumettre à nouveau la demande.
412	Le serveur n'a pas réussi à satisfaire une ou plusieurs des conditions préalables indiquées dans les champs d'en-tête de la requête. 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 la requête actuelle car la taille des données d'entité soumises par la requête dépasse la plage 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 plus tard il pourra 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 et 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 (Query String) 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 exploiter l'URI demandé. 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 requête actuelle et la ressource demandée, l'entité soumise dans la requête n'est pas dans un format pris en charge par le serveur, la requête est donc rejetée.
416	Si la requête contient l'en-tête de 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, alors le serveur devrait renvoyer le 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 Content-Type.
417	Le contenu attendu spécifié dans l'en-tête de la requête 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 de Expect ne peut pas être satisfait sur le prochain nœud du courant itinéraire. .
421	Le nombre de connexions au serveur à partir de l'adresse IP où se trouve le client actuel 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 nombre de connexions au serveur à partir de l'adresse IP du client actuel 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 requête est correct, mais elle ne peut pas répondre en raison d'erreurs sémantiques. (RFC 4918 WebDAV) 423 Verrouillé La ressource actuelle est verrouillée. (RFC 4918 WebDAV)
424	La requête actuelle a échoué en raison d'une erreur dans une requête précédente, telle que PROPPATCH. (RFC 4918 WebDAV)
425	Défini dans le brouillon WebDav Advanced Collections, mais n'apparaît pas dans le "WebDAV Sequence Collection Protocol" (RFC 3658).
426	Les clients doivent passer à TLS/1.0. (RFC 2817)
449	Extension par Microsoft Représente que les demandes doivent être réessayées après avoir effectué les actions appropriées.
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 une fonctionnalité requise par la requête actuelle. 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 fonctionnant comme passerelle ou proxy a reçu une réponse non valide du serveur en amont lors de la tentative d'exécution d'une requête.
503	En raison d'une maintenance temporaire du serveur ou d'une surcharge, le serveur est actuellement incapable de traiter les demandes. 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	Lorsqu'un serveur fonctionnant comme passerelle ou proxy tente d'exécuter une requête, il ne parvient pas à recevoir une réponse à temps du serveur en amont (le serveur identifié par l'URI, tel que HTTP, FTP, LDAP) ou le serveur auxiliaire (tel que DNS). Remarque : Certains serveurs proxy renvoient une erreur 400 ou 500 lorsque la requête DNS expire. 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	Extendu par le Transparent Content Négociation Protocol (RFC 2295) et représente une erreur de configuration interne dans le serveur : 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 est donc traitée dans une négociation est pas une orientation appropriée.
507	Le serveur ne peut pas stocker le contenu nécessaire pour compléter la demande. Cette condition est considérée comme temporaire. WebDAV (RFC 4918)
509	Le serveur a atteint la limite de bande passante. Il ne s’agit pas d’un code de statut officiel, mais il est encore largement utilisé.
510	Les stratégies nécessaires pour obtenir des ressources ne sont pas insatisfaites. (RFC 2774)
	Apprentissage recommandé : "

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!