On 31/05/2014 14:57, Konstantin Kolinko wrote: > 2014-05-29 16:31 GMT+04:00 Mark Thomas <ma...@apache.org>: >> 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. >> > > (1) Will it work with AJP/mod_jk? We can close the AJP connection, but > it is Apache HTTPD who is responsible for the chunked encoding.
Don't know. This needs some code review and/or testing. > (2) With HTTP/1.0 (no chunked encoding and no length set) the > connection will be closed both for successful and unsuccessful > responses, so there is no way to tell them apart. Agreed. Not much we can do about this. > (3) If there are any caching HTTP proxies in the way, can they tell > apart aborted connection vs. properly closed one? I would hope so but that isn't guaranteed. Certainly the current behaviour makes this harder so the proposed change should be an improvement. > As such, I think the only reliable way for client to check that the > whole response was delivered is to check for some end-of-data marker, > such as </html> tag or closing '}' in JSON. I agree. > Because of (3) your change may be worth pursuing. Because of (1) I > think it is not worth pursuing, unless we can force HTTPD to behave in > the same way. There is also benefit for those who use Tomcat directly. > (Some other consistency check ideas do not fly: > - Checksums. You do not know those for dynamically generated data. > - Trailing headers in the last chunk of a chunked encoding. As the > encoding is hop-to-hop, they may be lost by proxies. They are not > supported by AJP protocol and by current API. > ) Yep. > Fixing the timeout effect of "2." is worth pursuing. > > I also remember encountering the following oddity: > When an unexpected error occurs on a JSP page, all the text that have > not already been sent to the client is lost. > -> reproducible, filed as > https://issues.apache.org/bugzilla/show_bug.cgi?id=56581 > (I have not investigated whether that is caused by ErrorReportValve, > or by JSP buffering. It may be the latter.) Ah. I thought that might be related when I saw it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
