我测试HttpResponse#flushBuffer及PrintWriter#flush上Tomcat 7下方,但它似乎是回应,而忽略了他们比超过冲洗尽快预期电线的内容。
HttpResponse#flushBuffer
PrintWriter#flush
Tomcat 7
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"); } }
延迟后,浏览器同时显示“ hi”和“ bye”。这是不当行为还是故意的?
@编辑
根据@Tomasz Nurkiewicz的建议,我再次进行curl了测试,然后问题消失了。似乎标准浏览器和tcp/ip monitor打包small pieces of contents来自相同的http响应以将它们呈现在一起。
@Tomasz Nurkiewicz
curl
tcp/ip monitor
small pieces of contents
@编辑2
它也观察到,HttpResponse#flushBuffer并且PrintWriter#flush驱动器Tomcat 7发送客户端分块数据。
的API flushBuffer()非常精确:
flushBuffer()
强制将缓冲区中的任何内容写入客户端 。对此方法的调用将自动提交响应,这意味着将写入状态代码和标头。
因此,要么未按照规范实施Tomcat(要么更积极地缓冲缓冲区,如果刷新太小,则保持刷新),或者客户端(浏览器)在实际渲染之前等待更多输入。
你可以尝试用卷曲或nc代替?
nc