2014-05-29 14:31 GMT+02:00 Mark Thomas <ma...@apache.org>: > 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. >
In this particular case, I did it on purpose, I thought I had the opportunity to return a well formed response, but no possibility in the protocol to report an error, hence the behavior. Now what you say makes sense, so if you want to change it ... Rémy
