Codes de reponse du serveur. Description des codes d'en-tete HTTP.
Code d'etat HTTP - le code d'etat fait partie de la premiere ligne de la reponse du serveur. C'est un nombre entier de 3 chiffres arabes. Le premier chiffre indique la classe de la condition. Le code de reponse est generalement suivi d'une phrase explicative en anglais, separee par un espace, qui explique a la personne la raison de cette reponse particuliere. Exemple :

403 Acces autorise uniquement pour les utilisateurs enregistres

Le client apprend a partir du code de reponse les resultats de sa demande et determine les actions qu'il doit entreprendre ensuite. L'ensemble des codes d'etat est une norme, et ils sont tous decrits dans les RFC correspondants. L'introduction de nouveaux codes ne devrait etre faite qu'apres consultation avec l'IETF. Le client peut ne pas connaitre tous les codes d'etat, mais il est de la responsabilite du client de repondre en fonction de la classe du code.

Actuellement, il existe cinq classes de codes d'etat :

1xx : informatif : la demande a ete recue et comprise, mais le traitement se poursuit.
2xx : Succes - La demande a ete recue, comprise et traitee avec succes.
3xx : Redirection : des mesures supplementaires doivent etre prises pour terminer la demande.
4xx : Erreur client : la requete a une mauvaise syntaxe ou n'a pas pu etre effectuee.
5xx : Erreur du serveur : le serveur ne peut pas repondre a une demande valide.
Vous trouverez ci-dessous les codes de reponse du registre des codes de statut IANA.

1xx : informatif

Cette classe contient des codes qui informent sur le processus de transmission. En HTTP / 1.0, les messages avec de tels codes doivent etre ignores. En HTTP / 1.1, le client doit etre pret a accepter cette classe de message comme une reponse normale, mais rien ne doit etre envoye au serveur. Les messages du serveur eux-memes ne contiennent que la ligne de debut de la reponse et, si necessaire, quelques champs d'en-tete specifiques a la reponse. Les serveurs proxy doivent envoyer ces messages plus loin du serveur au client.

100 Continuer Le serveur est satisfait des details initiaux de la requete. Le client peut continuer a envoyer des en-tetes.

101 Switching Protocols (Russe. Switching protocols) Le serveur propose de basculer vers un protocole plus adapte a la ressource specifiee. Le serveur doit indiquer la liste des protocoles proposes dans le champ d'en-tete Update. Si le client est interesse par cela, alors il envoie une nouvelle requete indiquant un protocole different.

102 Traitement La demande a ete acceptee, mais son traitement sera long. Utilise par le serveur pour empecher le client d'abandonner la connexion en raison d'un delai d'attente. A la reception d'une telle reponse, le client doit reinitialiser le compteur et attendre la prochaine commande en mode normal.

2xx : Succes

Les messages de cette classe informent sur les cas d'acceptation et de traitement reussis de la demande d'un client. Selon le statut, le serveur peut egalement transmettre les en-tetes et le corps du message.

200 OK Requete reussie. Si le client a demande des donnees, elles se trouvent dans l'en-tete et/ou le corps du message.

201 Cree Une nouvelle ressource a ete creee suite a l'execution reussie de la requete. Le serveur doit indiquer son emplacement dans l'en-tete Location. Il est egalement recommande au serveur d'indiquer dans l'en-tete les caracteristiques de la ressource creee (par exemple, dans le champ Content-Type). Si le serveur n'est pas sur que la ressource existera reellement au moment ou le client recoit ce message, il est alors preferable d'utiliser la reponse 202.

202 Acceptee La demande a ete acceptee pour traitement, mais le traitement n'est pas termine. Le client n'a pas a attendre la transmission finale du message, car un processus tres long peut etre lance.

203 Informations ne faisant pas autorite Similaire a la reponse 200, mais dans ce cas, les informations transmises ne proviennent pas de la source principale (copie de sauvegarde, autre serveur, etc.) et peuvent donc ne pas etre a jour.

204 Pas de contenu Le serveur a traite avec succes la demande, mais seuls les en-tetes sans corps de message ont ete envoyes dans la reponse. Le client n'a pas besoin de mettre a jour le contenu du document, mais peut lui appliquer les metadonnees recues.

205 Reinitialiser le contenu Le serveur oblige le client a demander les donnees saisies par l'utilisateur. En meme temps, le serveur ne transmet pas le corps du message, et il n'est pas necessaire de mettre a jour le document.

206 Contenu partiel Le serveur a termine avec succes la demande du client, mais n'a transfere qu'une partie du document. Le serveur peut envoyer une telle reponse s'il existe un champ Content-Range dans l'en-tete de requete du client. Une attention particuliere doit etre accordee a la mise en cache lorsque vous travaillez avec de telles reponses.

207 Multi-Status (Russe. Multi-status) Le serveur transmet les resultats de plusieurs operations independantes a la fois. Ils sont places dans le mess age corps lui-meme en tant que document XML avec un seul objet multi-etats. Il n'est pas recommande de placer des statuts de la serie 1xx dans cet objet en raison de son insignifiance et de sa redondance.

226 IM utilise L'en-tete A-IM du client a ete recu avec succes et

le serveur renvoie le contenu en fonction des parametres specifies.

3xx : Redirection

Les codes d'etat de la classe 3xx indiquent au client de faire la prochaine requete a un URI different afin de terminer avec succes l'operation. Dans la plupart des cas, la nouvelle adresse est specifiee dans le champ d'en-tete Location. Dans ce cas, le client doit, en regle generale, effectuer une transition automatique (jargon redirection).

Notez que lorsque vous accedez a la ressource suivante, vous pouvez obtenir une reponse de la meme classe de code. Cela peut meme entrainer une longue chaine de redirections, qui, si elles etaient effectuees automatiquement, creeraient une charge excessive sur l'equipement. Par consequent, les developpeurs du protocole HTTP recommandent fortement qu'apres la deuxieme ligne d'une telle reponse, assurez-vous de demander la confirmation de la redirection a l'utilisateur (cela etait auparavant recommande apres le 5). Il est de la responsabilite du client de surveiller cela, puisque le serveur actuel peut rediriger le client vers une ressource sur un autre serveur. Le client doit egalement l'empecher d'etre pris dans les redirections a tour de role.

300 choix multiples Selon l'URI specifie, il existe plusieurs options pour fournir une ressource par type MIME, langage ou autres caracteristiques. Le serveur envoie une liste d'alternatives avec un message, donnant la possibilite de faire un choix au client ou a l'utilisateur.

301 Moved Permanently Le document demande a finalement ete deplace vers le nouvel URI specifie dans le champ Location de l'en-tete. Pour les requetes autres que la methode HEAD, le serveur doit transmettre une explication hypertexte dans le corps du message. Lorsque vous utilisez toutes les methodes a l'exception de GET et POST, vous devez d'abord informer l'utilisateur du changement de lien. N'oubliez pas que certains agents changent par erreur la methode POST en GET apres avoir bascule vers une autre adresse.

302 Trouve Le document demande a ete temporairement deplace vers un autre URI specifie dans l'en-tete du champ Emplacement. Pour toutes les methodes sauf HEAD, le serveur doit transmettre une explication hypertexte dans le corps. Lorsque vous utilisez toutes les methodes autres que GET et POST, vous devez d'abord informer l'utilisateur du changement d'URI. Lors de l'acces a la ressource suivante, la methode POST doit etre changee en GET comme le font certains agents.

303 Voir Autre Le document a l'URI demande doit etre demande par l'adresse dans le champ d'en-tete Location en utilisant la methode GET, meme si le premier a ete demande par la methode POST. Si une methode non HEAD est utilisee, le serveur DEVRAIT inclure une courte description hypertexte dans le corps du message.

304 Non modifie Le serveur renvoie ce code si le client a demande un document a l'aide de la methode GET, a utilise le champ Date dans l'en-tete et que le document n'a pas change depuis le moment specifie. Dans ce cas, le message du serveur ne doit pas contenir de corps.

305 Use Proxy La requete a la ressource demandee doit etre effectuee via un serveur proxy dont l'URI est specifie dans le champ d'en-tete Location. Ce code de reponse ne peut etre utilise que par les serveurs HTTP natifs (pas les proxys).

306 (Reserve) Utilise auparavant. Actuellement reserve.

307 Redirection temporaire La ressource demandee est disponible pendant une courte periode uniquement par un URI different (specifie dans le champ d'en-tete Location). Si une methode non HEAD a ete envoyee, le serveur DEVRAIT inclure une courte description hypertexte dans le corps du message. Lorsque vous utilisez toutes les methodes sauf GET et POST, vous devez d'abord informer l'utilisateur d'un changement de lien temporaire.

4xx : Erreur client

La classe de codes 4xx est destinee a indiquer les erreurs cote client. Lors de l'utilisation de toutes les methodes sauf HEAD, le serveur doit renvoyer une explication hypertexte a l'utilisateur dans le corps du message.

400 Bad Request La requete n'a pas ete comprise par le serveur en raison d'une erreur de syntaxe. Le client doit acceder a nouveau a la ressource avec la demande modifiee.

401 Non autorise La demande necessite une identification de l'utilisateur. Le client doit demander a l'utilisateur un nom et un mot de passe et les transmettre dans les enregistrements d'en-tete WWW-Authenticate lors de la prochaine demande. En cas de saisie de donnees erronees, le serveur retournera le meme statut.

402 Paiement requis (reserve) A utiliser a l'avenir. Actuellement non utilise.

403 Interdit Le serveur a compris la requete, mais il refuse de la satisfaire en raison de certaines restrictions d'acces. L'authentification via HTTP n'aidera pas ici. Tres probablement, le serveur doit s'authentifier d'une maniere differente, faire une demande avec certains parametres ou satisfaire certaines conditions.

404 Not Found Le serveur a compris la requete, mais n'a pas trouve de ressource correspondante a l'URI specifie. Si le serveur sait qu'il y avait un document a cette adresse, alors il est preferable d'utiliser le code 410 a la place. Ce code peut etre utilise a la place du 403 si vous devez soigneusement cacher certaines ressources aux regards indiscrets.

405 Methode non autorisee

f pris en charge) La methode specifiee par le client ne peut pas etre appliquee a la ressource. Le serveur doit egalement envoyer le champ Autoriser avec une liste des methodes disponibles dans l'en-tete de reponse.

406 Not Acceptable L'URI demande n'a pas pu satisfaire les specifications de l'en-tete. Si la methode n'etait pas HEAD, alors le serveur devrait renvoyer une liste de caracteristiques acceptables pour cette ressource.

Authentification proxy 407 requise La reponse est similaire au code 401, sauf que l'authentification est effectuee pour le serveur proxy. Le mecanisme est similaire a l'identification sur un serveur classique.

408 Request Timeout Le serveur a expire pour une transmission du client. Le client peut repeter la demande similaire a la precedente a tout moment.

409 Conflit La demande n'a pas pu etre traitee en raison d'un appel conflictuel a la ressource. Ceci est possible, par exemple, lorsque deux clients tentent de modifier une ressource a l'aide de la methode PUT.

410 Gone (russe. Supprime) Cette reponse est envoyee par le serveur lorsque la ressource etait auparavant a l'URI specifie, mais a ete supprimee et est desormais indisponible. Dans ce cas, le serveur ne connait pas l'emplacement du document alternatif (par exemple, une copie). Si le serveur soupconne que le document peut etre restaure dans un proche avenir, il est preferable d'envoyer le code 404 au client.

411 Longueur requise Pour la ressource specifiee, le client doit specifier le Content-Length dans l'en-tete de la requete. Sans specifier ce champ, vous ne devez pas faire une deuxieme tentative pour demander au serveur en utilisant cet URI.

412 Precondition Failed Renvoye si aucun des champs conditionnels de l'en-tete de la requete n'a ete rempli.

413 Request Entity Too Large (russe. Les donnees demandees sont trop volumineuses) Renvoye si le serveur, pour une raison quelconque, ne peut pas transferer la quantite d'informations demandee. Si le probleme est temporaire, le serveur peut indiquer dans le champ Retry-After le delai apres lequel une requete similaire peut etre repetee.

414 Request-URI Too Long Le serveur ne peut pas traiter la requete car l'URI specifie est trop long. Une telle erreur peut etre declenchee, par exemple, lorsque le client essaie de passer des parametres longs via la methode GET plutot que POST.

415 Type de media non pris en charge Pour une raison quelconque, le serveur refuse de travailler avec le type de donnees specifie avec cette methode.

416 Requested Range Not Satisfiable Le champ Range de l'en-tete de demande a specifie une plage en dehors de la ressource et le champ If-Range est manquant. Si le client a passe une plage d'octets, le serveur peut renvoyer la taille reelle dans le champ d'en-tete Content-Range. Cette reponse ne doit pas etre utilisee lors du passage de plusieurs parties / octets.

417 Expectation Failed Pour une raison quelconque, le serveur ne peut pas satisfaire la valeur du champ Expect dans l'en-tete de la requete.

422 Entite non traitable Le serveur a accepte la demande avec succes, peut fonctionner avec le type de donnees specifie, le document XML dans le corps de la demande a la syntaxe correcte, mais il y a une sorte d'erreur logique en raison de laquelle il est impossible d'effectuer une operation sur la ressource.

423 Verrouille La ressource cible de la requete est verrouillee a partir de la methode specifiee qui lui est appliquee.

424 Failed Dependency La mise en ?uvre de la requete en cours peut dependre du succes d'une autre operation. S'il n'a pas ete complete et qu'a cause de cela il est impossible de repondre a la demande en cours, le serveur renverra le code 424.

426 Mise a niveau requise Le serveur demande au client de mettre a niveau le protocole. L'en-tete de reponse doit contenir des champs de mise a niveau et de connexion bien formes.

5xx : Erreur de serveur

Des codes 5xx sont attribues pour les cas d'echec d'operation dus a une panne du serveur. Pour toutes les situations autres que l'utilisation de la methode HEAD, le serveur doit inclure une explication dans le corps du message que le client affichera a l'utilisateur.

Erreur de serveur interne 500 Toute erreur de serveur interne qui n'entre pas dans le champ d'application des autres erreurs de classe 5xx.

501 Non implemente Le serveur ne prend pas en charge les capacites requises pour traiter la demande. Reponse typique pour les cas ou le serveur ne comprend pas la methode specifiee dans la requete.

502 Bad Gateway Le serveur agissant en tant que passerelle ou proxy a recu un message indiquant que l'operation intermediaire a echoue.

503 Service indisponible Le serveur est temporairement incapable de traiter les demandes pour des raisons techniques (maintenance, surcharge, etc.). Dans le champ Retry-After de l'en-tete, le serveur peut specifier le temps apres lequel le client est r

Derniers sites analyses