Pregunta ¿El uso del encabezado Location en la respuesta HTTP 202 es compatible con RFC?


Tengo una gran discusión conceptual con mis compañeros de trabajo sobre el uso del encabezado de ubicación en 202 respuesta aceptada.

La historia comenzó a analizar el comportamiento de la función de encabezado PHP () desde aquí. El interesante extracto:

El segundo caso especial es el encabezado "Ubicación:". No solo devuelve este encabezado al navegador, sino que también devuelve un código de estado REDIRECT (302) al navegador, a menos que el código de estado 201 o 3xx ya se haya configurado.

No incluyeron el código de estado 202 en este comportamiento predeterminado. Parece que no esperan que la respuesta 202 tenga una Ubicación y de hecho:

header("HTTP/1.1 202");
header("Location: http://example.com");

redirigir al cliente a la URL de ubicación. Por supuesto, es posible cambiar este comportamiento con el tercer parámetro de la función header (), pero lo que me llamó la atención fue: ¿Por qué entendieron que, por defecto, 202 no se espera que contenga un encabezado Location?

Luego repasé el RFC buscando el significado oficial del estado 202. El interesante extracto:

La entidad devuelta con esta respuesta DEBERÍA incluir una indicación del estado actual de la solicitud y un puntero a un monitor de estado o alguna estimación de cuándo el usuario puede esperar que se cumpla la solicitud.

No se refiere explícitamente al encabezado de ubicación como lo hace la respuesta 201 anterior (en el mismo documento RFC). Esa sería probablemente la razón por la cual los chicos de PHP entendieron que la respuesta 202 no debería contener el encabezado de Ubicación. ¿Se interpretaría un puntero como encabezado de ubicación o PHP chicos hizo una suposición incorrecta? Si el estándar permite el encabezado de ubicación con la respuesta 202: ¿no debería ser la documentación oficial más explícita como la definición de respuesta 201?

Finalmente revisé más recientemente RFC versión y encontrar un pequeño cambio en la redacción:

La representación enviada con esta respuesta debe describir el estado actual de la solicitud y señalar a (o insertar) un monitor de estado que proporciona al usuario una estimación de cuándo se cumplirá la solicitud.

De nuevo, no es lo suficientemente explícito como para suponer que apunta a significa encabezado de ubicación.

En resumen, después de las revisiones anteriores: ¿Estoy cumpliendo con RFC usando el encabezado Location con la respuesta 202?


14
2017-10-05 03:03


origen


Respuestas:


Finalmente, recibí una respuesta de R. Fielding:

enter image description here

202 es un estado de éxito. El puntero mencionado es solo hipertexto en el cuerpo de la respuesta.   Se debe enviar un 303 si desea usar la ubicación para redirigir el cliente a otro recurso. El resultado de la solicitud redirigida puede ser un 202.

.... Roy

Por lo tanto, el encabezado Location no se debe usar en 202 Accepted respuesta. Los chicos de PHP hicieron la interpretación correcta.

Editar marzo de 2017: Lo siento, olvidé agregar otros mensajes que intercambiamos en el mismo hilo en ese momento, así que estoy publicando ahora para el registro:

yo:  Sobre el sección 4.1 de la RFC 7240el autor (J. Snell) da un ejemplo usando el encabezado Location en 202 respuesta aceptada. ¿Está equivocado? Es como si muchas personas entendieran este comportamiento de RFC 7231. ¿Pueden enviarme alguna referencia sobre este controvertido problema?

Roy:  El ejemplo se da sin instrucción, por lo que no está equivocado porque él no dice lo que significa. La ubicación se puede enviar en cualquier mensaje. Lo que significa solo está definido para ciertos códigos de estado.

Por ejemplo, si él hubiera dicho que el agente de usuario haría uso de ese campo Ubicación para proporcionar un indicador de estado al usuario, luego él habría estado equivocado. Puede ser una buena idea, pero no es parte del estándar.

PHP hace una suposición errónea de que la ubicación solo se usa en 201 y 3xx respuestas, pero está permitido hacerlo porque su API interna no es HTTP; en su lugar, traduce la secuencia a HTTP.

No hay controversia Para ser parte del estándar, en al menos dos implementaciones independientes tendrían que mostrar el mismo comportamiento. En este caso, ninguno lo hace.


17
2017-10-06 16:20



De RFC-2616:

La entidad devuelto con esta respuesta DEBERÍA incluir una indicación del estado actual de la solicitud y un puntero a un monitor de estado o alguna estimación de cuándo el usuario puede esperar que se cumpla la solicitud.

Creo que la clave aquí es "la entidad", ya que la pregunta aquí es si incluimos la indicación de estado en los encabezados de respuesta o en el cuerpo de respuesta. Casi en todas partes se hace referencia a una entidad, parece implicar el cuerpo de respuesta. Por ejemplo:

10.5 Error de servidor 5xx

Los códigos de estado de respuesta que comienzan con el dígito "5" indican casos en los que el servidor sabe que se ha equivocado o que no puede realizar la solicitud. Excepto cuando se responde a una solicitud HEAD, el servidor DEBERÍA incluir una entidad que contenga una explicación de la situación de error, y si se trata de una condición temporal o permanente. Agentes de usuario DEBERÍA mostrar cualquier entidad incluida al usuario. Estos códigos de respuesta son aplicables a cualquier método de solicitud.

No he visto un navegador mostrar encabezados de respuesta a un usuario. Y para 303s:

10.3.4 303 Ver otros

Los diferentes URI DEBERÍAN darse por el campo Ubicación en la respuesta. A menos que el método de solicitud fuera HEAD, la entidad de la respuesta DEBERÍA contener una breve nota de hipertexto con un hipervínculo al nuevo URI (s).

No obtendrá una respuesta de hipertexto en los encabezados.

Sin embargo, sección 7 es bastante claro sobre a qué se refiere la entidad:

Una entidad consta de campos de encabezado de entidad y un cuerpo de entidad, aunque algunas respuestas solo incluirán los encabezados de entidad.

Creo que en tu caso, lo que estás haciendo es compatible con RFC-2616. Sin embargo, de manera realista todo esto se reduce a la implementación del cliente. ¿Puede el cliente que recibe su respuesta 202 manejar un Location: encabezado para un 2xx ¿respuesta? Esa debería ser su prueba de fuego para saber cómo responder, y también es la prueba utilizada para impulsar los estándares durante su estandarización / documentación.


7
2017-10-05 03:17



En realidad, según el rfc 7240 http://tools.ietf.org/html/rfc7240#section-4.1 puede enviar un código de estado 202 junto con un encabezado de ubicación. Eso estaría en una respuesta asincrónica, sin embargo, aparentemente, PHP no te permitirá hacerlo.


2
2017-10-24 14:16



El RFC admite que es vago en ese concepto. Esto significa que la especificación actualmente no dice cómo se usa "Ubicación" con 202, pero, por otro lado, no es una licencia para que las bibliotecas simplemente reemplacen el código de estado. Entonces este es definitivamente un error de PHP.


-1
2017-10-05 07:22