¿Qué código de estado http se supone que debe usarse para decirle al cliente que se agotó el tiempo de espera de la sesión?

En una página web, utiliza el administrador de conexión / fuente de datos YUI para enviar solicitudes AJAX al servidor, si la sesión (que contiene la información sobre si el usuario ha sido autenticado) ya ha agotado el tiempo de espera, esas respuestas ajax que solo pueden ser vistas por autenticados los usuarios deben devolver un código de estado http, indicándole al cliente que la sesión ya ha agotado el tiempo de espera, luego el cliente simplemente lo redirige a la página de inicio de sesión o le pregunta si quiere extender la sesión.

Mi pregunta es que, en esta situación, ¿qué código de estado http es el más apropiado para decirle al cliente que se agotó el tiempo de espera de la sesión?

Lista de códigos de estado HTTP de wiki

Lo mejor que puedo sugerir es un código de estado HTTP 401 con un encabezado WWW-Authenticate.

El problema con las solicitudes 403 es que el RFC 2616 dice "La autorización no ayudará y la solicitud NO DEBE repetirse". (es decir, no importa si está autenticado o no, nunca tendrá acceso a ese recurso).

El problema con las solicitudes 401 es que indica que "DEBEN incluir un campo de encabezado WWW-Authenticate". Como alguien ha notado , no parece infringir la especificación utilizar un valor personalizado en un encabezado WWW-Authenticate.

No veo ninguna razón en RFC 2617 por la que un estado HTTP 401 combinado con un encabezado WWW-Authenticate personalizado como este no estaría bien:

WWW-Authenticate: MyAuthScheme realm="http://example.com"

La especificación oAuth realmente parece hacer exactamente esto, ya que recomiendan esto (aunque en mi opinión tienen una interpretación extraña del RFC):

WWW-Authenticate: OAuth realm="http://server.example.com/"

Esto no parece estar específicamente SANCIONADO por el RFC, pero en realidad no puedo ver que esté prohibido por él (no parece entrar en conflicto con ninguna condición DEBE o NO DEBE, DEBE o NO DEBE).

Desearía que hubiera un código de estado HTTP más específico para los tiempos de espera y para cosas como los tokens CSRF que no son válidos para que esto sea más claro.

Recomendaría un HTTP 401.

Mientras que un 403 básicamente dice: "No tienes permiso, vete y no vuelvas", un 401 dice: "No sabemos si tienes permiso o no porque no trajiste tu identificación. Ir consígalo y vuelva a intentarlo ".

Compare las definiciones de Wikipedia :

HTTP 403 : la solicitud era una solicitud legal, pero el servidor se niega a responder.

HTTP 401 : similar a 403 Prohibido, pero específicamente para usar cuando la autenticación es posible pero ha fallado o aún no se ha proporcionado.

¿Qué pasa con 419? No es estándar, pero la descripción en Wikipedia parece encajar:

419 Tiempo de espera de autenticación

No es parte del estándar HTTP, 419 Authentication Timeout denota que la autenticación previamente válida ha expirado. Se utiliza como alternativa a 401 No autorizado para diferenciar a los clientes autenticados a los que se les niega el acceso a recursos específicos del servidor.

Creo que el código apropiado será 403 / Prohibido. No hay ninguno que esté directamente relacionado con las sesiones.

La verdad es que no existe un código de estado HTTP estándar para un tiempo de espera de sesión. Las sesiones se implementan en la capa de aplicación, no en la capa de transporte HTTP.

Hay un código de estado personalizado que Microsoft ha estado usando para el tiempo de espera de la sesión: 599, o simplemente cree su propio código de estado en el rango 5xx.

Desde el Wiki de códigos de estado:

599 Error de tiempo de espera de conexión de red (Desconocido) Este código de estado no se especifica en ningún RFC, pero los proxies HTTP de Microsoft Corp. lo utilizan para indicar un tiempo de espera de conexión de red detrás del proxy a un cliente frente al proxy.

Utilizo el código de estado personalizado 599 para un tiempo de espera de sesión y luego lo verifico en la respuesta de AJAX.

Según el enlace de Wikipedia de los códigos de estado Http proporcionados anteriormente por Bobo:

440 Login Timeout (Microsoft)

    A Microsoft extension. Indicates that your session has expired.

Al publicar un enlace, en ese enlace encontré este código de estado HTTP 440 . puede utilizar el código de estado HTTP 440 para la sesión caducada.

440 Tiempo de espera de inicio de sesión

 The client's session has expired and must log in again.

401 No autorizado, podemos usarlo cuando la credencial de inicio de sesión del usuario es incorrecta. o el token de autenticación pasado en el encabezado no es válido.

403 Prohibido, podemos usar esto cuando el usuario no tiene un permiso específico para el recurso solicitado.

Entonces, en mi opinión, deberíamos usar 440 Login Time-out .

Técnicamente, la respuesta aceptada es, por supuesto, correcta: si ya sabe con certeza que va a fallar la solicitud y está preguntando qué código de falla devolver, entonces HTTP 401 "No autorizado (no autenticado)" es el apropiado, para solicitar una nueva autenticación.

Pero antes que nada, pregúntate: debería rechazar la solicitud?

Tenga en cuenta que el usuario puede simplemente estar visitando una página pública de su sitio web, en cuyo caso le va a dar una bofetada en la cara con un "¡No autorizado!" mensaje y exigirles que se vuelvan a autenticar para ver una página que normalmente podrían ver sin autenticación. Eso no es cool.

Mi consejo es ignorar el hecho de que el token de sesión es desconocido y simplemente proceder a generar un nuevo token de sesión y crear una nueva sesión para él. El estado inicial de la sesión, por supuesto, será "aún no autenticado", por lo que si el usuario está intentando acceder a una página no pública, la página se encargará de que reciba un HTTP 401 "No autorizado (no autenticado) "y debe autenticarse. Pero si el usuario llega a una página pública, no notará nada diferente.

Usaría una respuesta de redirección 302, con un encabezado de "Ubicación" que dirija a una ruta de recursos como "/ auth-required"

El cliente podría enrutar la ruta del recurso a un modal con un formulario de inicio de sesión / contraseña, evitando transferir al usuario a otra página.

Para las solicitudes que no son Ajax, utilizo una redirección 302.

Para las solicitudes de Ajax, utilizo 200 para errores conocidos . De esa forma puedo aprovechar el objeto de datos. Encuentro que el objeto de datos es más fácil de trabajar que analizar jqXHR para obtener información. Y luego no necesito preocuparme por qué código de estado HTTP intentar reutilizar para mi situación.

Ejemplo de jQuery:

$.ajax({
    //send data to server
})
.done(function(data, textStatus, jqXHR) {
    if (data.success) {
        //then process return data
    }
    else {
        //get error type or message from data object
        //could use custom error codes
    }
})
.fail(function(jqXHR, textStatus, errorThrown) {
    //handle unknown errors
});

Código 408. "Solicitar tiempo de espera", parece perfecto: RFC 2616 explica que significa

El cliente no produjo una solicitud dentro del tiempo que el servidor estaba preparado para esperar.

es decir, exactamente un "tiempo muerto", ¡tal como lo necesita!