You've probably noticed I've been poking around the ErrorReportValve, the Response objects and other related code. I've been looking into an issue that one of the groups at $work has raised around Tomcat's error handling and I've been cleaning things up as I notice them to stop me getting distracted while I try and concentrate on the larger problem.
I've also spotted a few places where I think we are duplicating functionality unnecessarily. I'm trying to clean this up as well. Partly because it is more efficient and partly because the code is easier to follow without it. So, that larger problem... It is to do with how uncaught exceptions are handled. There are four variations: 1. Content length set, some content written, response not committed. 2. Content length set, some content written, response committed. 3. Content length not set, some content written, response not committed. 4. Content length not set, some content written, response committed. Variation 1 & 3 are easy. The response has not been committed so the ErrorReportingValve resets the response and writes an error response instead. In both cases it is clear to the client that there was an error. Variation 2 is not handled so well. The ErrorReportValve can't set the status code nor can it write content so an incomplete response is sent to the client. The client then waits for the rest of the response (since the content length header is set) and eventually times out (actually I think Tomcat times out the connection waiting for the next request). Variation 4 is also not handled well. The ErrorReportValve can't set the status code nor can it write content so an incomplete response is sent to the client. Because chunked encoding is being used, Tomcat ends the request with an end chunk so, to the client, it looks like a complete response. Depending on the content, it may or may not be clear to the client that an incomplete response has been received. It is variation 4 that is causing problems at work but variation 2 looks problematic as well. My current thinking is to do something in the ErrorReportValve so that when an uncaught exception occurs after the response is committed Tomcat flushes what valid data it has and then closes the connection. In the case of chunked encoding this would be done *without* sending the end chunk to make it clear to the client that the response is truncated. For variation 2 this immediate close would stop the client waiting for the timeout to occur before realising that the response was incomplete. I haven't quite settled on exactly how to do this yet but while I am pondering that problem any feedback on the overall problem and proposed solution would be appreciated. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
