Created attachment 35839 [details] log of the Exception When an IOException that occurred while writing the response doesn't bubble up the through the Servlet.service and a jsp error page is specified, the following Exception will happen when tomcat tries to render the jsp: 2018-04-04 18:33:04 SEVERE org.apache.catalina.core.ApplicationDispatcher invoke Servlet.service() for servlet [jsp] threw exception java.lang.IllegalStateException: getOutputStream() has already been called for this response [...] 2018-04-04 18:33:04 SEVERE org.apache.catalina.core.StandardHostValve custom Exception Processing ErrorPage[errorCode=0, location=/error.jsp] org.apache.jasper.JasperException: java.lang.IllegalStateException: getOutputStream() has already been called for this response It's reproductible with a ClientAbortException: call a page that take long time to write the response and interrupt that call (ctr+c on curl). See this project for example: https://github.com/guillaumecle/tomcat-error-page This doesn't happen in 9.0.5, only 9.0.6. I beleive it's related to bug 41007
I don't see what the refactoring could have changed here at this point. The problem is the response is committed (really, as you wrote data) and so that's why there's an include (which fails as you saw). This behavior to try to report an error despite possible problems could be made optional, it's rather weird IMO in a more "modern" website setting.
There are multiple things going on here. 1. The sample application doesn't reproduce the issue described here. An ISE is thrown but it is thrown because the error JSP tries to create a session. Once: <%@ page session="false" %> is added to the JSP error page, then the sample application reproduces the error described here. 2. The ISE is thrown because JSPs always use writers. This makes them a poor choice for error pages where pages that may experience errors use OutputStreams and may have committed the response before the error occurs. Static error pages are generally better as the DefaultServlet has code to handle the OutputStream or Writer case. 3. There is little point producing an error page after an error has occurred that has closed the connection to the client. 1 & 2 represent common problems with using JSPs as error pages. A likely side effect of the changes in bug 41007 - that caused more errors to be passed to the error handling mechanism - is that we will probably see more reports as a result of using JSP error pages inappropriately. 3 is something that we can address. I have committed an enhancement for this to 9.0.x.
>3 is something that we can address. I have committed an enhancement for this to 9.0.x. This is awesome. I'll test it when the next version is released.
I confirmed the bug is fixed.
Error handling changes were back-ported to 8.5.x meaning this fix needed to be back-ported as well. Fixed in 8.5.x for 8.5.44 onwards.
*** Bug 63662 has been marked as a duplicate of this bug. ***