Cuando un usuario no está conectado e intenta acceder a una página que requiere inicio de sesión, ¿cuál es el código de estado HTTP correcto para una redirección a la página de inicio de sesión?
Pregunto porque ninguno de los códigos de respuesta 3xx establecidos por el W3C parece cumplir con los requisitos:
10.3.1 300 opciones múltiples
El recurso solicitado corresponde a cualquiera de un conjunto de representaciones, cada una con su propia ubicación específica, y se proporciona información de negociación dirigida por el agente (sección 12) para que el usuario (o agente de usuario) pueda seleccionar una representación preferida y redirigir su solicitud a esa ubicación.
A menos que se trate de una solicitud HEAD, la respuesta DEBE incluir una entidad que contenga una lista de características de recursos y ubicaciones de las cuales el usuario o agente de usuario puede elegir la más adecuada. El formato de entidad se especifica por el tipo de medio dado en el campo de encabezado Tipo de contenido. Dependiendo del formato y las capacidades de
el agente de usuario, la selección de la opción más apropiada PUEDE realizarse automáticamente. Sin embargo, esta especificación no define ningún estándar para dicha selección automática.
Si el servidor tiene una opción preferida de representación, DEBE incluir el URI específico para esa representación en el campo Ubicación; los agentes de usuario PUEDEN usar el valor del campo Ubicación para la redirección automática. Esta respuesta se puede almacenar en caché a menos que se indique lo contrario.
10.3.2 301 Movido permanentemente
Al recurso solicitado se le ha asignado un nuevo URI permanente y cualquier referencia futura a este recurso DEBERÍA usar uno de los URI devueltos. Los clientes con capacidades de edición de enlaces deben volver a vincular automáticamente las referencias al Request-URI a una o más de las nuevas referencias devueltas por el servidor, cuando sea posible. Esta respuesta se puede almacenar en caché a menos que se indique lo contrario.
El nuevo URI permanente DEBE ser proporcionado por el campo Ubicación en la respuesta. A menos que el método de solicitud sea HEAD, la entidad de la respuesta DEBERÍA contener una breve nota de hipertexto con un hipervínculo a los nuevos URI.
Si el código de estado 301 se recibe en respuesta a una solicitud que no sea GET o HEAD, el agente de usuario NO DEBE redirigir automáticamente la solicitud a menos que pueda ser confirmada por el usuario, ya que esto podría cambiar las condiciones bajo las cuales se emitió la solicitud.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.10.3.3 302 encontrado
El recurso solicitado reside temporalmente bajo un URI diferente. Debido a que la redirección puede ser alterada ocasionalmente, el cliente DEBE continuar usando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si se indica mediante un campo de encabezado Cache-Control o Expires.
El URI temporal DEBE ser dado por el campo Ubicación en la respuesta. A menos que el método de solicitud sea HEAD, la entidad de la respuesta DEBE contener una breve nota de hipertexto con un hipervínculo a los nuevos URI.
Si se recibe el código de estado 302 en respuesta a una solicitud que no sea GET o HEAD, el agente de usuario NO DEBE redirigir automáticamente la solicitud a menos que pueda ser confirmada por el usuario, ya que esto podría cambiar las condiciones bajo las cuales se emitió la solicitud.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if itfueron una respuesta 303, realizando un GET en el valor del campo Ubicación, independientemente del método de solicitud original. Los códigos de estado 303 y 307 se han agregado para los servidores que desean dejar inequívocamente claro qué tipo de reacción se espera del cliente.
10.3.4 303 Ver otros
La respuesta a la solicitud se puede encontrar bajo un URI diferente y DEBE recuperarse utilizando un método GET en ese recurso. Este método existe principalmente para permitir que la salida de un script activado por POST redirija al agente de usuario a un recurso seleccionado. El nuevo URI no es una referencia sustitutiva del recurso solicitado originalmente. La respuesta 303 NO DEBE almacenarse en caché, pero la respuesta a la segunda solicitud (redirigida) puede ser almacenable en caché.
Los diferentes URI DEBEN ser dados por el campo Ubicación en la respuesta. A menos que el método de solicitud sea HEAD, la entidad de la respuesta DEBE contener una breve nota de hipertexto con un hipervínculo a los nuevos URI.
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.10.3.5 304 No modificado
Si el cliente ha realizado una solicitud GET condicional y se permite el acceso, pero el documento no se ha modificado, el servidor DEBE responder con este código de estado. La respuesta 304 NO DEBE contener un cuerpo de mensaje y, por lo tanto, siempre termina con la primera línea vacía después de los campos de encabezado.
La respuesta DEBE incluir los siguientes campos de encabezado:
- Date, unless its omission is required by section 14.18.1 If ael servidor de origen sin reloj obedece estas reglas, y los servidores proxy y los clientes agregan su propia Fecha a cualquier respuesta recibida sin una (como ya se especifica en [RFC 2068], sección 14.19), los cachés funcionarán correctamente.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request - Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant If the conditional GET used a strong cache validator (seesección 13.3.3), la respuesta NO DEBE incluir otros encabezados de entidad. De lo contrario (es decir, el GET condicional utilizó un validador débil), la respuesta NO DEBE incluir otros encabezados de entidad; Esto evita inconsistencias entre los cuerpos de entidad en caché y los encabezados actualizados.
Si una respuesta 304 indica una entidad que actualmente no está en caché, entonces el caché DEBE ignorar la respuesta y repetir la solicitud sin el condicional.
Si un caché usa una respuesta 304 recibida para actualizar una entrada de caché, el caché DEBE actualizar la entrada para reflejar los nuevos valores de campo dados en la respuesta.
10.3.6 305 Usar proxy
Se debe acceder al recurso solicitado a través del proxy proporcionado por el campo Ubicación. El campo Ubicación proporciona el URI del proxy. Se espera que el destinatario repita esta solicitud única a través del proxy. Las respuestas 305 DEBEN ser generadas únicamente por los servidores de origen.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.10.3.7 306 (sin usar)
El código de estado 306 se usó en una versión anterior de la especificación, ya no se usa y el código está reservado.
10.3.8 307 Redirección temporal
El recurso solicitado reside temporalmente bajo un URI diferente. Dado que la redirección PUEDE ser alterada ocasionalmente, el cliente DEBE continuar utilizando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si se indica mediante un campo de encabezado Cache-Control o Expires.
El URI temporal DEBE ser dado por el campo Ubicación en la respuesta. A menos que el método de solicitud sea HEAD, la entidad de la respuesta DEBE contener una breve nota de hipertexto con un hipervínculo a los nuevos URI, ya que muchos agentes de usuario anteriores a HTTP / 1.1 no entienden el estado 307. Por lo tanto, la nota DEBE contener la información necesaria para que un usuario repita la solicitud original en el nuevo URI.
Si se recibe el código de estado 307 en respuesta a una solicitud que no sea GET o HEAD, el agente de usuario NO DEBE redirigir automáticamente la solicitud a menos que pueda ser confirmada por el usuario, ya que esto podría cambiar las condiciones bajo las cuales se emitió la solicitud.
Estoy usando 302 por ahora, hasta que encuentre la respuesta correcta.
Actualización y conclusión:
HTTP 302 es mejor ya que se sabe que tiene la mejor compatibilidad con clientes / navegadores.