redireccionamiento - ¿Cuál es el código de estado HTTP correcto al redireccionar a una página de inicio de sesión?

redireccionar una pagina web a otro dominio (4)

Creo que la solución adecuada es el encabezado HTTP 401 (no autorizado).

http://en.wikipedia.org/wiki/HTTP_codes#4xx_Client_Error

El propósito de este encabezado es exactamente esto. Pero, en lugar de redireccionar a una página de inicio de sesión, el proceso correcto sería algo así como:

Usuario no registrado intente acceder a una página restringida para iniciar sesión.
el sistema identifica que el usuario no está conectado
el sistema devuelve el encabezado HTTP 401, Y muestra el formulario de inicio de sesión en la misma respuesta (no una redirección).

Esta es una buena práctica, como proporcionar una página 404 útil, con enlaces de mapa del sitio y un formulario de búsqueda, por ejemplo.

Nos vemos.

Cuando un usuario no está conectado y trata de acceder a una página que requiere iniciar sesión, ¿cuál es el código de estado HTTP correcto para un redireccionamiento a la página de inicio de sesión?

Pregunto porque ninguno de los códigos de respuesta 3xx establecidos por el W3C parece ajustarse a 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 solicitar a esa ubicación.
A menos que se trate de una solicitud HEAD, la respuesta DEBERÍA incluir una entidad que contenga una lista de características de los recursos y ubicación (es) a partir de la cual el usuario o agente de usuario puede elegir la más apropiada. El formato de entidad se especifica según el tipo de medio que se proporciona 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, DEBERÍA incluir el URI específico para esa representación en el campo Ubicación; las agencias de usuario PUEDEN usar el valor del campo Ubicación para la redirección automática. Esta respuesta es cacheable 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 URI de solicitud a una o más de las nuevas referencias devueltas por el servidor, cuando sea posible. Esta respuesta es cacheable a menos que se indique lo contrario.
El nuevo URI permanente DEBE estar dado 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).
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 el usuario pueda confirmarla, 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. Como la redirección podría verse alterada ocasionalmente, el cliente DEBERÍA continuar utilizando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si está indicada por un campo de encabezado Cache-Control o Expires.
El URI temporal DEBE estar dado 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).
Si el código de estado 302 se recibe en respuesta a una solicitud que no sea GET o HEAD, el agente de usuario NO DEBE redireccionar automáticamente la solicitud a menos que el usuario pueda confirmarla, 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 it
fueron una respuesta 303, realizando un GET en el campo de valor de la 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 aclarar inequívocamente 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 DEBERÍA recuperarse utilizando un método GET en ese recurso. Este método existe principalmente para permitir que la salida de una secuencia de comandos activada POST redirija el agente de usuario a un recurso seleccionado. El nuevo URI no es una referencia sustituta para el recurso solicitado originalmente. La respuesta 303 NO DEBE almacenarse en caché, pero la respuesta a la segunda solicitud (redireccionada) puede almacenarse en caché.
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).
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 DEBERÍA 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 a
el servidor de origen sin reloj obedece estas reglas, y los proxies y los clientes agregan su propia fecha a cualquier respuesta recibida sin ella (como ya se especificó en [RFC 2068], sección 14.19), las memorias caché 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 (see
sección 13.3.3), la respuesta NO DEBE incluir otros encabezados de entidad. De lo contrario (es decir, el GET condicional utiliza un validador débil), la respuesta NO DEBE incluir otros encabezados de entidad; esto evita las incoherencias entre los cuerpos de entidad almacenados en caché y los encabezados actualizados.
Si una respuesta 304 indica una entidad que no está actualmente en la memoria caché, entonces la memoria 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 cualquier valor nuevo de campo dado en la respuesta.
10.3.6 305 Usar proxy
El recurso solicitado DEBE accederse 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 única solicitud a través del proxy. 305 respuestas DEBEN ser generadas solo 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 utilizó 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 usando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si está indicada por un campo de encabezado Cache-Control o Expires.
El URI temporal DEBE estar dado 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), ya que muchos agentes de usuario anteriores a HTTP / 1.1 no entienden el estado 307. Por lo tanto, la nota DEBERÍA contener la información necesaria para que un usuario repita la solicitud original en el nuevo URI.
Si el código de estado 307 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 el usuario pueda confirmarla, 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.

Diría que ~~303 ven otros~~ 302 encontrados:

El recurso solicitado reside temporalmente bajo un URI diferente. Como la redirección podría verse alterada ocasionalmente , el cliente DEBERÍA continuar utilizando el URI de solicitud para futuras solicitudes. Esta respuesta solo se puede almacenar en caché si está indicada por un campo de encabezado Cache-Control o Expires.

se ajusta a una página de inicio de sesión más de cerca en mi opinión. Inicialmente consideré que 303 see other que funcionaría igual de bien. Después de pensarlo un poco, diría que 302 Found es más adecuado porque se encontró el recurso solicitado, simplemente hay que pasar otra página antes de que se pueda acceder. La respuesta no se almacena en caché de manera predeterminada, lo que también está bien.

Este es un mal uso del mecanismo de redireccionamiento HTTP. Si un usuario no está autorizado, entonces su aplicación debe devolver 401 no autorizado . En caso de que el usuario esté autorizado pero no tenga acceso al recurso solicitado, debe devolverse 403 Prohibido .

Debe hacer la redirección en el lado del cliente, por ejemplo, mediante javascript. código de estado para la redirección porque la autorización requerida no existe . Usar 30x para esto no se ajusta a HTTP.

Tuve casos raros en que el navegador Firefox guardó en caché la redirección 302. Esa es la razón por la que estoy usando 307 para las páginas de inicio de sesión y, por ejemplo, redirige al último artículo / publicación / comentario / etc.

Si está utilizando 302, no olvide verificar que el almacenamiento en caché esté desactivado:

header(''Expires: Mon, 26 Jul 1997 05:00:00 GMT''); header(''Last-Modified: '' . gmdate(''D, d M Y H:i:s'') . '' GMT''); header(''Cache-Control: no-cache''); header(''Pragma: no-cache''); header(''Cache-Control: post-check=0, pre-check=0'', false);