On 29/05/2014 16:54, Rémy Maucherat wrote: > 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 ...
Thanks for the background. It helps a lot to confirm that I haven't missed something. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
