¿Puede un servidor http detectar que un cliente ha cancelado su solicitud?

request-cancelling

Question

Mi aplicación web debe procesar y proporcionar una gran cantidad de datos para mostrar ciertas páginas. A veces, el usuario cierra o actualiza una página mientras el servidor todavía está ocupado procesándola. Esto significa que el servidor continuará procesando los datos durante varios minutos solo para enviarlos a un cliente que ya no está escuchando.

¿Es posible detectar que la conexión se ha roto y reaccionar a ella?

En este proyecto en particular, estamos usando Django y NginX, o Apache. Asumí que esto es posible porque el servidor de desarrollo de Django parece reaccionar a las solicitudes canceladas imprimiendo excepciones de Broken Pipe. Me encantaría que generara una excepción que el código de mi aplicación pudiera detectar. Parece que JSP puede hacer esto . Así puede hacer node.js here .

Alternativamente, podría registrar un controlador de eventos de descarga en la página en cuestión, hacer que haga un XHR síncrono solicitando que se cancele la solicitud anterior de este usuario y hacer algún tipo de comunicación entre procesos para hacerlo. Quizás si el procesamiento de datos más lento se pasara a otro proceso que pudiera identificar y matar más fácilmente, sin matar el proceso de respuesta ...

Answer 1

HTTP no tiene estado, por lo tanto, la única forma de detectar un cliente desconectado es a través de los tiempos de espera.

Vea las respuestas a esta pregunta SO (Java Servlet: ¿Cómo detectar el cierre del navegador?).

Answer 2

Si bien @Oded es correcto en que HTTP no tiene estado entre las solicitudes, los servidores de aplicaciones pueden detectar cuándo se rompió la conexión TCP / IP subyacente para la solicitud que se procesa . ¿Por qué es esto? Porque TCP es un protocolo de estado para conexiones confiables.

Una técnica común para las aplicaciones web .Net que procesan una solicitud intensiva de recursos es verificar Response.IsClientConnected ( docs ) antes de comenzar el trabajo intensivo de recursos. No tiene sentido perder ciclos de CPU para enviar una respuesta costosa a un cliente que ya no está allí.

private void Page_Load(object sender, EventArgs e)
{
    // Check whether the browser remains
    // connected to the server.
    if (Response.IsClientConnected)
    {
        // If still connected, do work
        DoWork();
    }
    else
    {
        // If the browser is not connected
        // stop all response processing.
        Response.End();
    }
}

Responda con la pila del servidor de la aplicación de destino para que pueda proporcionar un ejemplo más relevante.

Con respecto a su segunda alternativa para usar XHR para publicar eventos de descarga de la página del cliente en el servidor, el comentario de @Oded sobre el hecho de que HTTP no tiene estado entre las solicitudes es correcto. Es poco probable que esto funcione, especialmente en una granja de servidores con varios servidores.