markt wrote
> On 06/06/17 15:08, Thomas Eliassen wrote:
> ...
>
> I think we are going to have to choose a "least bad" option here. Given
> that Tomcat has used 200 in the past and that there is the option to add
> %{javax.servlet.error.exception}r to the access log I think reverting
> the change to the status code is the best (well, least bad) option here.
>
> I'll get that done shortly.
>
> Mark
I saw that the change was kind of reverted with Revision 1797829 in
http://svn.apache.org/repos/asf/tomcat/tc8.5.x/trunk/java/org/apache/coyote/AbstractProcessor.java
- but it does not work for me.
When I stop a request from within the client the method is called with an
ErrorState.CLOSE_NOW and t=null. Thus !(t instanceof IOException) is true
and the status will be set to 500 again.
Maybe it would make more sense to check for
if (response.getStatus() < 400 && errorState.isIoAllowed())
// then set to 500, otherwise it was probably a client disconnect
I also saw that with 8.5.20 the %X accessLog format was added, which I might
be able to use to differentiate between "real" 500 server-errors and client
disconnects.
Best Regards
Andreas
--
View this message in context:
http://tomcat.10.x6.nabble.com/Change-of-status-code-for-ClientAbortExceptions-bug-tp5063738p5066604.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
