HTTP 400 (mauvaise requête) pour erreur logique, syntaxe non malformée

Question

La spécification HTTP/1.1 (RFC 2616) a ceci à dire sur la signification du code d'état de 400 Bad Request (§10.4.1):

La demande ne peut pas être compris par le serveur en raison de la malformation de la syntaxe. Le client ne DOIT PAS répéter l' demande sans modifications.

Il semble être une pratique courante entre quelques HTTP-Api en fonction de ces jours d'utilisation 400 à dire une logique plutôt que d'une syntaxe erreur avec une demande. Ma conjecture est que les Api sont en train de faire cette distinction entre 400 (client-induite) et 500 (serveur-induite). Est-il acceptable ou incorrect d'utiliser de 400 à indiquer une non-syntaxique des erreurs? Si elle est acceptable, est-il annoté de référence sur la RFC 2616, qui fournit des précisions sur l'utilisation prévue de 400?

Exemples:

• Google de Données de Protocole de, Protocole de Référence, les Codes d'État HTTP

Answer 1

Statut 422 (RFC 4918, Section 11.2) vient à l'esprit:

Les 422 (Unprocessable Entité) code du statut signifie que le serveur comprend le type de contenu de la demande de l'entité (d'où un 415(Unsupported Media Type) code d'état est inapproprié), et la syntaxe de l'entité de la requête est correcte (donc un 400 (Bad Request) code d'état est inapproprié), mais n'a pas pu traiter le contenu des instructions. Par exemple, cette condition d'erreur peut se produire si une requête XML corps contient bien formé (c'est à dire, syntaxiquement correctes), mais sémantiquement erronée, instructions XML.

Answer 2

Dès cette époque, le dernier projet de la HTTPbis cahier des charges, qui est destiné à remplacer, et de le rendre obsolète la RFC 2616, les états:

Les 400 (Bad Request) code d'état indique que le serveur ne peut pas ou ne pas traiter la demande car le reçu de la syntaxe n'est pas valide, absurde, ou dépasse certaines limites à ce que le serveur est prêt de processus.

Cette définition, bien que toujours sujet à des changements, ratifie la pratique largement utilisée de répondre à la logique des erreurs avec un 400.

Answer 3

HTTPbis traitera le libellé de 400 demandes incorrectes 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 traitera pas la demande en raison d'une erreur du client (par exemple, une syntaxe mal formée)"

Answer 4

Même si, j'ai été en utilisant 400 pour représenter la logique des erreurs aussi, je dois dire que le retour de 400 qui est mauvais dans ce cas, en raison de la façon dont les spec lit. Ici, c'est pourquoi je pense que oui, l'erreur de logique pourrait être qu'une relation avec une autre entité a échoué ou n'ont pas satisfait et apporter des modifications à l'autre entité pourrait provoquer exactement la même de passer plus tard. Comme tentent de le faire (complètement hypothétique) ajouter un employé en tant que membre d'un service lorsque l'employé n'existe pas (erreur de logique). L'ajout d'employé à titre de membre de la requête peut é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 les juges d'interpréter la langue dans la RFC ces jours :)

Merci, Vish

Answer 5

Il pourrait être soutenu que le fait d'avoir des données incorrectes dans votre demande est une erreur de syntaxe, même si votre demande réelle au niveau HTTP (demande en ligne, en-têtes, etc) est syntaxiquement valide.

Par exemple, si un service web Restful qui est documenté en acceptant des Postes avec un custom XML Type de Contenu de application/vnd.example.com.widget+xml, et à la place vous envoyer un peu du charabia texte brut ou d'un fichier binaire, il semble resasonable à la traiter comme une erreur de syntaxe - votre corps de la requête n'est pas dans la forme attendue.

Je ne sais pas du tout des références officielles pour bien que, comme d'habitude, elle semble être en panne à l'interprétation de la RFC 2616.