http - pagina - ¿Cuáles son los códigos de estado adecuados para las solicitudes de verificación previa de CORS?

http/1.1 200 ok

Question

¿Qué código de estado debe devolver un servidor HTTP bien escrito cuando recibe una solicitud de verificación previa de CORS ( OPTIONS )?

200 , 204 o algo mas?

¿Debería el código de estado ser diferente en caso de que se permita el origen (y se establecerán los encabezados correspondientes) o no se permitirá (y los encabezados CORS no se establecerán o no coincidirán con el origen)?

Answer 1

La esencia de esto es, solo usa 200 .

Un poco más generalmente: simplemente debe devolver el mismo código de estado para la solicitud de OPTIONS verificación previa de CORS que enviaría de vuelta para cualquier otra solicitud de OPTIONS . Las especificaciones relevantes no requieren ni recomiendan nada más que eso.

En cuanto a las especificaciones relevantes: La especificación Fetch en https://fetch.spec.whatwg.org/ es donde se definen los requisitos para el protocolo CORS, y dice que el estado puede ser cualquiera entre 200 y 299 .

Eso es del algoritmo de búsqueda de verificación previa de CORS , que tiene un paso que dice que puede ser cualquier "estado correcto" :

Si una verificación CORS de solicitud y respuesta devuelve el éxito y el estado de la respuesta es
un estado correcto , ejecute estos subpasos: ...

Y en cuanto a lo que es un "estado correcto", la especificación dice esto:

Un estado correcto es cualquier estado en el rango 200 a 299 , 299 inclusive.

Más allá de eso, sin embargo, la especificación Fetch no recomienda ningún estado en particular dentro de 200 - 299 .

La otra especificación relevante aquí es la especificación HTTP 1.1, que tiene una sección que define la semántica de todos los códigos de estado de respuesta HTTP, y dentro de eso, una sección específica que define los códigos 2xx exitosos .

Y dentro de esa sección hay una sección específica para 200 OK , que dice esto:

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;

Por lo tanto, una respuesta a las OPCIONES de verificación previa de CORS solo tiene que ser:

• una indicación de que la solicitud ha tenido éxito
• una representación de las opciones de comunicación (que en este caso incluye los Access-Control-Allow-Headers respuesta Access-Control-Allow-Methods y Access-Control-Allow-Headers )

Eso es lo que 200 OK define la especificación de HTTP, de modo que puede detenerse allí mismo.

Pero si leyó el resto de los códigos 2xx en esa sección , puede confirmar que la semántica de ninguno de ellos tiene sentido para una respuesta de OPTIONS , a excepción de 204 No Content .

Ahora, en cuanto a 204 No Content go, no hay nada de malo en usarlo para las respuestas de OPTIONS , pero, por lo que puedo ver, tampoco hay realmente ningún punto. Eso es porque:

• a diferencia de otros métodos, la especificación HTTP no define el uso de una carga útil OPTIONS
• por lo tanto, en la práctica, los clientes no esperan que ninguna carga útil (contenido) regrese por OPTIONS (y no haría nada con ninguna carga útil que regresó)

... por lo que puedo ver, no hay un propósito práctico en el uso de un código de estado 204 específico en una respuesta de OPTIONS para indicar explícitamente a los clientes que no hay carga útil.

Es posible que pueda estar equivocado, sin embargo, y hay algunos matices que me estoy perdiendo. Pero no lo creo.

¿Debería el código de estado ser diferente en caso de que se permita el origen (y se establecerán los encabezados correspondientes) o no se permitirá (y los encabezados CORS no se establecerán o no coincidirán con el origen)?

No, no creo que deba ser diferente. No sé qué código definido estándar, aparte de 200 o 204 , podría usar de todos modos, pero independientemente de eso, las especificaciones no requieren que sea diferente y no definen un uso diferente si lo es. Y piénselo: ¿qué va a hacer cualquier código de cliente diferente de manera diferente debido a cualquier diferencia en los códigos de estado para esos dos casos?

Si la respuesta a esa pregunta es "Nada" , por lo que puedo ver, no tiene sentido hacerlo diferente.

Teniendo en cuenta todo lo anterior, la conclusión es: simplemente envíe 200 OK para las respuestas OPTIONS de verificación previa de CORS. Enviar cualquier código que no sea 200 OK no es necesario ni útil.