Erreur client 4xx

La classe 4xx de code d'état est destinée aux cas dans lesquels le client semble s'être trompé. Excepté lorsqu'il répond à une demande HEAD, le serveur DEVRAIT inclure une entité contenant une explication de la situation

d'erreur, et s'il s'agit d'une condition temporaire ou permanente. Ces codes d'état sont applicables à toute méthode de demande. Les agents d'utilisateur DEVRAIENT afficher à l'utilisateur toutes les entités incluses.

Si le client envoie des données, une mise en œuvre de serveur utilisant TCP DEVRAIT être attentive à s'assurer que le client accuse réception du ou des paquets contenant la réponse, avant que le serveur ne close la connexion d'entrée. Si le client continue d'envoyer des données au serveur après la clôture, la pile TCP du serveur enverra un paquet de rétablissement au client, qui peut écraser la mémoire tampon d'entrée non acquittée du client avant qu'elles puissent être lues et interprétées par l'application HTTP.

10.4.1 400 Mauvaise demande

La demande n'a pas pu être comprise par le serveur à cause d'une syntaxe mal formée. Le client NE DEVRAIT PAS répéter la demande sans modifications.

10.4.2 401 Non autorisé

La demande exige une authentification de l'utilisateur. La réponse DOIT inclure un champ d’en-tête WWW-Authenticate (paragraphe 14.47) contenant une mise en cause applicable à la ressource demandée. Le client PEUT répéter la demande avec un champ d’en-tête Authorization convenable (paragraphe 14.8). Si la demande a déjà inclus les accréditifs d'autorisation, la réponse 401 indique alors que l'autorisation a été refusée pour ces accréditifs. Si la réponse 401 contenait la même mise en cause que la réponse précédente, et si l'agent d’utilisateur a déjà essayé l'authentification au moins une fois, l'utilisateur DEVRAIT être alors mis en présence de l'entité qui est donnée dans la réponse, car cette entité peut inclure des informations de diagnostic pertinentes. L'authentification d'accès HTTP est expliquée dans "Authentification HTTP : Authentification d'accès de base et par résumé" [43].

10.4.3 402 Paiement exigé

Ce code est réservé pour une utilisation future.

10.4.4 403 Interdit

Le serveur a compris la demande, mais refuse de la satisfaire. L'autorisation ne sert à rien et la demande NE DEVRAIT PAS être répétée. Si la méthode de la demande n'était pas HEAD et si le serveur souhaite rendre publique la raison pour laquelle la demande n'a pas été satisfaite, il DEVRAIT décrire la raison du refus dans l'entité. Si le serveur ne souhaite pas rendre ces informations disponibles au client, le code d'état 404 (Pas trouvé) peut être utilisé à la place.

10.4.5 404 Pas trouvé

Le serveur n'a rien trouvé qui corresponde à l'URI de demande. Aucune indication n'est donnée sur le fait que la condition soit temporaire ou permanente. Le code d'état 410 (Parti) DEVRAIT être utilisé si le serveur sait, par un mécanisme configurable en interne, qu'une ancienne ressource est indisponible de façon permanente et n'a pas d'adresse de renvoi. Ce code d'état est couramment utilisé lorsque le serveur ne souhaite pas révéler exactement pourquoi la demande a été refusée, ou lorsque aucune autre réponse n'est applicable.

10.4.6 405 Méthode non admise

La méthode spécifiée dans la ligne de demande n'est pas admise pour la ressource identifiée par l'URI de demande. La réponse DOIT inclure un en-tête Allow contenant une liste des méthodes valides pour la ressource demandée.

10.4.7 406 Non acceptable

La ressource identifiée par la demande est seulement capable de générer des entités de réponse qui ont des caractéristiques de contenu non acceptables selon les en-têtes d'acceptation envoyés dans la demande.

Sauf s'il s'agit d'une demande HEAD, la réponse DEVRAIT inclure une entité contenant une liste des caractéristiques et localisations d'entité disponibles entre lesquelles l'utilisateur ou agent d’utilisateur peut choisir celle qui est la plus appropriée. Le format d'entité est spécifié par le type de support donné dans le champ d'en-tête Content-Type. Selon le format et les capacités de l'agent d’utilisateur, le choix le plus approprié PEUT être effectué automatiquement. Cependant, la présente spécification ne définit aucune norme pour un tel choix automatique.

Note : Les serveurs HTTP/1.1 sont autorisés à retourner des réponses qui ne sont pas acceptables selon les en-têtes d'acceptation envoyés dans la demande. Dans certains cas, ceci peut même être préférable à l'envoi d'une réponse 406. Les agents d'utilisateur sont invités à inspecter les en-têtes d'une réponse entrante pour déterminer si elle est acceptable.

Si la réponse pourrait être inacceptable, un agent d’utilisateur DEVRAIT temporairement arrêter la réception des données et interroger l'utilisateur sur la décision à prendre quant aux actions ultérieures.

10.4.8 407 Authentification du mandataire exigée

Ce code est similaire à 401 (Non autorisé), mais indique que le client doit d'abord s'authentifier auprès du mandataire. Le mandataire DOIT retourner un champ d’en-tête Proxy-Authenticate (paragraphe 14.33) contenant une mise en cause applicable au mandataire pour la ressource demandée. Le client PEUT répéter la demande avec un champ d’en-tête Proxy-Authorization convenable (paragraphe 14.34). L'authentification d'accès HTTP est expliquée dans "Authentification HTTP : Authentification d'accès de base et par résumé" [43].

10.4.9 408 Expiration du délai de la demande

Le client n'a pas produit une demande dans le délai pendant lequel serveur était prêt à attendre. Le client PEUT répéter la demande sans modification à tout moment ultérieur.

10.4.10 409 Conflit

La demande n'a pas pu être achevée à cause d'un conflit avec l'état en cours de la ressource. Ce code n'est admis que dans des situations où on s'attend à ce que l'utilisateur soit capable de résoudre le conflit et soumettre à nouveau la demande. Le corps de la réponse DEVRAIT inclure suffisamment d'informations pour que l'utilisateur reconnaisse la source du conflit. En principe, l'entité de réponse devrait inclure des informations suffisantes pour que l'utilisateur ou l'agent d’utilisateur résolve le problème ; cependant, cela peut n'être pas possible et n'est pas exigé.

Les conflits vont le plus vraisemblablement survenir en réponse à une demande PUT. Par exemple, si le numéro de version devait être utilisé et si l'entité dans PUT inclut des changements à une ressource qui sont en conflit avec ceux faits par une demande précédente (de tierce partie), le serveur pourrait utiliser la réponse 409 pour indiquer qu'il ne peut achever la demande. Dans ce cas, l'entité de réponse va vraisemblablement contenir une liste des différences entre les deux versions dans un format défini par le type de contenu de la réponse.

10.4.11 410 Parti

La ressource demandée n'est plus disponible au serveur et aucune adresse de retransmission n'est connue.

Cette condition est en principe considérée comme permanente. Les clients avec des capacités d'édition de liens DEVRAIENT supprimer les références à l'URI de demande après approbation de l'utilisateur. Si le serveur ne sait pas, ou n'a pas de possibilité de déterminer si la condition est permanente ou non, le code d'état 404 (Non trouvé) DEVRAIT être utilisé à la place. Cette réponse peut être mise en antémémoire sauf indication contraire.

La réponse 404 est principalement destinée à aider aux tâches de maintenance de la toile en notifiant au receveur que la ressource est intentionnellement indisponible et que les propriétaires du serveur désirent que les liens distants à cette ressource soient supprimés. Un tel événement est courant pour une durée limitée, des services promotionnels et pour des ressources appartenant à des individus ne travaillant plus sur le site du serveur. Il n'est pas nécessaire de marquer toutes les ressources indisponibles de façon permanente comme

"parties" ou de conserver la marque pour une durée déterminée -- ceci est laissé à la discrétion du propriétaire

du serveur.

10.4.12 411 Longueur requise

Le serveur refuse d'accepter la demande sans une longueur de contenu définie. Le client PEUT répéter la demande si il ajoute un champ d’en-tête Content-Length valide contenant la longueur du corps de message dans le message de demande.

10.4.13 412 Échec de précondition

La précondition donnée dans un ou plusieurs des champs d’en-tête de la demande a été évaluée à faux lorsqu'ils ont été testés sur le serveur. Ce code de réponse permet au client de fixer des préconditions sur les méta-informations (données de champ d’en-tête) de la ressource en cours et empêcher ainsi que la méthode demandée ne soit appliquée à une ressource autre que celle désirée.

10.4.14 413 Entité de demande trop grande

Le serveur refuse de traiter une demande parce que l'entité de demande est plus grande que ce que le serveur est désireux ou capable de traiter. Le serveur PEUT clore la connexion pour empêcher le client de poursuivre la demande.

Si la condition est temporaire, le serveur DEVRAIT inclure un champ d’en-tête Retry-After (réessayer plus tard) pour indiquer que c'est temporaire et après quel délai le client PEUT essayer à nouveau.

10.4.15 414 URI de demande trop long

Le serveur refuse de servir la demande parce que l'URI de demande est plus long que ce que le serveur veut interpréter. Cette condition rare ne surviendra vraisemblablement que lorsqu'un client a improprement converti une demande POST en demande GET avec de longues informations d'interrogation, lorsque le client est descendu dans un URI de redirection "trou noir" (par exemple, un préfixe d'URI redirigé qui pointe sur un suffixe de lui-même), ou lorsque le serveur est soumis à une attaque par un client qui essaye d'exploiter des trous dans la sécurité présents sur certains serveurs utilisant des mémoires tampon de longueur fixe pour lire ou manipuler l'URI de demande.

10.4.16 415 Type de support non pris en charge

Le serveur refuse de servir la demande parce que l'entité de la demande est dans un format non pris en charge par la ressource demandée pour la méthode demandée.

10.4.17 416 Gamme demandée non acceptable

Un serveur DEVRAIT retourner une réponse avec ce code d'état si une demande inclut un champ d’en-tête de demande Range (paragraphe 14.35) et qu'aucune des valeurs de spécification de gamme de ce champ ne recouvre la dimension actuelle de la ressource choisie, et que la demande n'inclut pas un champ d’en-tête de demande If-Range. (Pour les gammes d'octet, cela signifie que les valeurs first-byte-pos de toutes les valeurs byte-range-spec sont supérieures à la longueur actuelle de la ressource choisie.)

Lorsque ce code d'état est retourné pour une demande byte-range, la réponse DEVRAIT inclure un champ d’en-tête d'entité Content-Range qui spécifie la longueur actuelle de la ressource choisie (voir au paragraphe 14.16). Cette réponse NE DOIT PAS utiliser le type de contenu multipart/byteranges.

10.4.18 417 Échec de l'attente

L'attente donnée dans un champ d’en-tête de demande Expect (voir au paragraphe 14.20) n'a pas pu être satisfaite par ce serveur, ou, si le serveur est un mandataire, le serveur a vu de façon non ambiguë que la demande ne pourra pas être satisfaite par le serveur du prochain bond.