https://issues.apache.org/bugzilla/show_bug.cgi?id=57476
--- Comment #11 from Mark Thomas <ma...@apache.org> --- I've found the root cause. It was triggered by r1643210 but I think all that did was uncover a different bug. It is easier to see if you go back to Tomcat 6 as that is before async was added. If you look at StandardHostValve line 136 [1] you'll see that the response is unsuspended unconditionally although the comment suggests it is being unsuspended for error handling (which may need to write to the response). In r1643210 that code was modified so the response was only unsuspended if there was an error to handle. This triggered the problem because the RequestDispatcher did not flush the response before calling finish(). Calling finish() sets suspended to true. The sequence was: a) page 1 forwards to page 2 b) page 2 writes response leaving some data in buffer c) RD calls finish which suspends response d) StandardHostValve unsuspends response e) normal end handling for page 1 flushes and closes the response r1643210 removed step d) which in turn prevented the flush in step e). Section 9.4 of the Servlet 3.1 spec says: <quote> Before the forward method of the RequestDispatcher interface returns without exception, the response content must be sent and committed, and closed by the servlet container, unless the request was put into the asynchronous mode. </quote> My reading of the spec is that we should be calling response.flushBuffer() before we call finish() in the RequestDispatcher. I am going to apply a patch to that effect to trunk, 8.0.x and 7.0.x shortly. I then intend to start an 8.0.x release. [1] http://svn.eu.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/core/StandardHostValve.java?view=annotate#l136 -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
