Tomcat no descarga el búfer de respuesta

Question

Probé HttpResponse#flushBuffer y PrintWriter#flush en Tomcat 7 debajo, pero parecía que la respuesta los ignoraba más que enjuagar el contenido por el cable lo antes posible.

import java.io.IOException; 
import java.io.PrintWriter; 

import javax.servlet.ServletException; 
import javax.servlet.annotation.WebServlet; 
import javax.servlet.http.HttpServlet; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 

@WebServlet("/HelloServlet") 
public class HelloServlet extends HttpServlet { 

    private static final long serialVersionUID = 1L; 

    protected void doGet(HttpServletRequest request, 
      HttpServletResponse response) throws ServletException, IOException { 

     PrintWriter pw = response.getWriter(); 
     pw.println("say hi now"); 
     pw.flush(); 
     response.flushBuffer(); 
     try { 
      Thread.sleep(5000); 
     } catch (Exception e) { 
     } 
     pw.println("say bye in 5 seconds"); 

    } 

} 

El navegador muestra "hola" y "adiós" juntos después de la demora. ¿Es una mala conducta o intencional?

@EDIT

De acuerdo con la sugerencia @Tomasz Nurkiewicz 's, he probado de nuevo con curl entonces el problema se ha ido. Parece que los navegadores estándar y tcp/ip monitor paquete small pieces of contents de la misma respuesta http para unirlos.

@EDIT 2

También se observó que tanto HttpResponse#flushBuffer y PrintWriter#flush unidad Tomcat 7 para enviar el cliente chunked data.

Answer 1

El API para flushBuffer() es muy preciso:

Fuerzas cualquier contenido en el búfer se escriban en el cliente. Una llamada a este método confirma automáticamente la respuesta, lo que significa que se escribirá el código de estado y los encabezados.

Por lo tanto, Tomcat no se implementa de acuerdo con la especificación (almacena más agresivamente y mantiene los colores si son demasiado pequeños) o el cliente espera más entradas antes de representarlo.

¿Puedes probar con curl o nc en su lugar?

Answer 2

Acabo de tener este mismo problema. Para detener los navegadores de espera hasta que la página termine de cargarse antes de que haga algún renderizado que necesita para empezar con:

response.setContentType("text/html;charset=UTF-8"); 

Answer 3

tuve ese problema, también. Y descubrí, también, que el problema desaparece con Curl. Con algo de olfateo, resultó que el culpable es la codificación gzip. Para comprimir la respuesta, gzip espera hasta que se cierra el PrintWriter subyacente (es decir, hasta que se escribe la respuesta completa) y luego produce la salida comprimida. En el lado del cliente, esto significa que no recibirá nada hasta que la respuesta completa esté lista. Curl, por otro lado, no emite un Accept-Encoding: gzip al servidor, y es por eso que funciona, y usted puede obtener la salida fragmentada normalmente como se esperaba.

Answer 4

Una posible causa aún no mencionada para este fenómeno es el software antivirus. Observé el mismo comportamiento en mi máquina: servidor enviando datos fragmentados, curl funcionó, los navegadores normales no lo hicieron, y también Fiddler confirmó que no fue el servidor quien bloqueó. Así que después de un tiempo sospeché de la protección web de Sophos (el software antivirus que usa mi empleador) para interferir, y de hecho confirman al https://community.sophos.com/kb/en-us/115656 que bloquean los datos fragmentados hasta que la respuesta se completa, excepto para ciertos tipos de mime que son a menudo se usa para transmitir datos multimedia.

Como una comprobación rápida, se puede ejecutar la demostración de HTTP-Push en http://www.pushlets.com.Si no funciona, es bastante probable que el cliente tenga un problema general al manejar datos fragmentados de tipo text/html correctamente.