web-dev-qa-db-fra.com

Quels sont les codes d'état appropriés pour les demandes de contrôle en amont CORS?

Quel code d'état un serveur HTTP bien écrit doit-il renvoyer lorsqu'il reçoit une demande de contrôle en amont CORS (OPTIONS)?

200, 204 ou autre chose?

Le code d'état doit-il être différent si l'origine est autorisée (et les en-têtes correspondants seront définis) ou non (et les en-têtes CORS ne seront pas définis ou ne correspondront pas à l'origine)?

httpcorshttp-status-codespreflight
25
Andrej

L'essentiel est, utilisez simplement 200.

Un peu plus généralement: vous devez simplement renvoyer le même code d’état pour la demande de contrôle en amont OPTIONS de CORS que vous devez renvoyer pour toute autre demande OPTIONS. Les spécifications pertinentes n'exigent ni ne recommandent rien de plus que cela.

En ce qui concerne les spécifications pertinentes: La spécification Fetch à https://fetch.spec.whatwg.org/ est l'endroit où les exigences pour le protocole CORS sont définies, et il indique que l'état peut être n'importe quoi dans la plage 200-299.

Cela provient de algorithme de récupération CORS-preflight , qui a ne étape indiquant qu'il peut s'agir de n'importe quel "état ok" :

Si un CORS vérifie demande et réponse renvoie le succès et réponse le statut de
an état ok , exécutez ces sous-étapes:…

Et en ce qui concerne le "statut ok", la spécification dit ceci:

Un état ok est un état de la plage 200 à 299, inclus.

Au-delà de cela, la spécification Fetch ne recommande aucun état particulier dans 200-299.

L'autre spécification pertinente ici est la spécification HTTP 1.1, qui a une section définissant la sémantique de tous les codes d'état de réponse HTTP, et à l'intérieur de cela, ne section spécifique qui définit Successful 2xx = codes.

Et dans cette section, il y a ne section spécifique pour 200 OK , qui dit ceci:

The 200 (OK) status code indicates that the request has succeeded.
The payload sent in a 200 response depends on the request method.
For the methods defined by this specification, the intended meaning
of the payload can be summarized as:
…
OPTIONS  a representation of the communications options;

Donc, une réponse à une OPTIONS de contrôle en amont CORS doit simplement être:

C'est ce que 200 OK est défini par la spécification HTTP, vous pouvez donc vous arrêter là.

Mais si vous lisez le reste du 2xx codes dans cette section , vous pouvez confirmer que la sémantique d'aucun d'entre eux n'a de sens pour une réponse OPTIONS — sauf pour 204 No Content .

Maintenant jusqu'à 204 No Content va, il n'y a rien mal en l'utilisant pour les réponses OPTIONS - mais pour autant que je puisse voir, il n'y a pas vraiment de point. C'est parce que:

  • contrairement à certaines autres méthodes, la spécification HTTP ne définit aucune utilisation pour une charge utile OPTIONS
  • par conséquent, dans la pratique, les clients ne s'attendent pas à ce qu'une charge utile (contenu) revienne pour un OPTIONS (et ne ferait rien avec une charge utile qui est revenue)

… Pour autant que je sache, il n'y a aucun intérêt pratique à utiliser un 204 code d'état dans une réponse OPTIONS pour indiquer explicitement aux clients qu'il n'y a pas de charge utile.

Il est possible que je me trompe, cependant, et il y a une nuance qui me manque. Mais je ne pense pas.

Le code d'état doit-il être différent si l'origine est autorisée (et les en-têtes correspondants seront définis) ou non (et les en-têtes CORS ne seront pas définis ou ne correspondront pas à l'origine)?

Non, je ne pense pas que ça devrait être différent. Je ne sais pas quel code défini en standard autre que 200 ou 204 vous pouvez utiliser de toute façon, mais indépendamment de cela, les spécifications n'exigent pas qu'il soit différent et ne définissent aucune utilisation différente si c'est le cas. Et pensez-y: qu'est-ce qu'un code client existant va faire différemment en raison d'une différence dans les codes d'état pour ces deux cas?

Si la réponse à cette question est, "Rien", pour autant que je puisse voir, il est inutile de le rendre différent.

Compte tenu de tout ce qui précède, la conclusion est la suivante: envoyez simplement 200 OK pour CORS preflight OPTIONS réponses. Envoi de tout code autre que simplement 200 OK n'est ni nécessaire ni utile.

29
sideshowbarker