tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Error handling
Date Mon, 02 Jun 2014 14:08:32 GMT
On 31/05/2014 14:57, Konstantin Kolinko wrote:
> 2014-05-29 16:31 GMT+04:00 Mark Thomas <markt@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message