HTTP 400 (mauvaise requête) pour une erreur logique, pas une mauvaise syntaxe de requête
le spécification HTTP/1.1 (RFC 2616) a le suivant à dire sur la signification de code d'état 400, mauvaise requête (§10.4.1) :
la requête ne peut être comprise par le serveur à cause d'une mauvaise syntaxe. Le client ne doit pas répéter demande sans modifications.
il semble y avoir une pratique générale parmi quelques API basées sur HTTP ces jours-ci pour utilisez 400 pour signifier une erreur logique plutôt qu'une erreur syntaxe avec une requête. À mon avis, les API font cette distinction entre 400 (induit par le client) et 500 (induit par le serveur). Est-il acceptable ou incorrect d'utiliser 400 pour indiquer des erreurs non syntaxiques? Si cela est acceptable, y a-t-il une référence annotée dans la RFC 2616 qui donne une meilleure idée de l'utilisation prévue de 400?
exemples:
6 réponses
statut 422 ( RFC 4918, Section 11.2 ) vient à l'esprit:
le code D'État 422 (Entité non traitable) signifie que le serveur comprend le type de contenu de l'entité de requête (par conséquent, un code d'état 415(Type de média non pris en charge) n'est pas approprié), et la syntaxe de l'entité de requête est correcte (par conséquent, un code d'état 400 (mauvaise requête) n'est pas approprié) mais n'a pas été en mesure de traiter les instructions contenues. Par exemple, cette erreur cette condition peut se produire si un corps de requête XML contient des instructions XML bien formées (c'est-à-dire syntaxiquement correctes), mais sémantiquement erronées.
à partir de ce moment, le dernier projet de la spécification HTTPbis , qui est destiné à remplacer et à rendre la RFC 2616 obsolète, déclare :
le code D'état 400 (mauvaise requête) indique que le serveur ne peut pas ou ne traitera pas la requête parce que la syntaxe reçue n'est pas valide, absurde, ou dépasse certaines limites à ce que le serveur est prêt de processus.
cette définition, tout en étant sujette à changement, entérine la pratique largement utilisée de répondre aux erreurs de logique avec un 400.
HTTPbis traitera le phrasé de 400 Bad Request afin qu'il couvre également les erreurs logiques. Donc 400 incorporera 422.
de https://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-18#section-7.4.1
"Le serveur ne peut pas ou ne veut pas traiter la requête, en raison d'une erreur du client (par exemple, syntaxe mal formée) "
bien que, j'ai utilisé 400 pour représenter des erreurs logiques aussi, je dois dire que rendre 400 est erroné dans ce cas en raison de la façon dont la spécification lit. C'est la raison pour laquelle je pense que l'erreur logique pourrait être qu'une relation avec une autre entité était défaillante ou non satisfaite et que le fait d'apporter des changements à l'autre entité pourrait faire en sorte que la même chose se produise plus tard. Comme essayer (complètement hypothétique) d'ajouter un employé comme membre d'un ministère lorsque cet employé n'existe pas (erreur de logique). L'ajout d'un employé à la demande d'un membre pourrait échouer parce que l'employé n'existe pas. Mais exactement la même demande pourrait passer après que l'employé a été ajouté au système.
juste mes 2 cents ... Nous avons besoin d'avocats et de juges pour interpréter le langage de la RFC de nos jours:)
Merci, Vish
on pourrait faire valoir que le fait d'avoir des données incorrectes dans votre requête est une erreur de syntaxe, même si votre requête actuelle au niveau HTTP (ligne de requête, en-têtes, etc.) est valide sur le plan syntaxique.
par exemple , si un service Web reposant est documenté comme acceptant des postes avec un type de contenu XML personnalisé de application/vnd.example.com.widget+xml , et que vous envoyez plutôt du texte brut ou un fichier binaire, il semble raisonnable de traiter cela comme une erreur de syntaxe - votre du corps de la requête n'est pas dans la forme attendue.
Je ne connais aucune référence officielle pour étayer cela, cependant, comme d'habitude, il semble qu'il s'agisse de l'interprétation de la RFC 2616.
mise à jour: noter le libellé révisé dans RFC 7231 §6.5.1 :
le code D'état 400 (mauvaise requête) indique que le serveur ne peut pas ou ne veut pas traiter la requête en raison de quelque chose qui est perception d'une erreur de la part du client, par exemple une syntaxe de requête mal formée, un cadrage de message de requête non valide ou un routage de requête trompeur).
semble soutenir cet argument plus que le maintenant obsolète RFC 2616 §10.4.1 qui a dit juste:
la requête n'a pas pu être comprise par le serveur en raison d'une mauvaise syntaxe. Le client ne doit pas répéter la requête sans modifications.
sur les serveurs Java EE un 400 est retourné si votre URL fait référence à une"application web" inexistante. C'est qu'une "erreur de syntaxe"? Cela dépend de ce que vous entendez par erreur de syntaxe. Je dirais que oui.
En anglais les règles de syntaxe prescrire certaines relations entre les parties du discours. Par exemple" Bob marries Mary " est syntaxiquement correct, car il suit le modèle {nom + verbe + nom}. Alors "Bob marriage Mary" serait syntaxiquement incorrect, {Nom + Nom + Nom}.
la syntaxe d'une URLis simple { protocol + : + // + server + : + port }. Selon ce " http://www.google.com:80 est syntaxiquement correct.
Mais quid de l'abc://www.google.com:80"? Il semble suivre exactement le même modèle. Mais vraiment c'est une erreur de syntaxe. Pourquoi? Parce que " abc " n'est pas un protocole défini.
le point est que déterminer si nous avons ou non une situation 400 nécessite plus que l'analyse des caractères, des espaces et des délimiteurs. Il doit également reconnaître que les "parties du discours".