On 06/06/17 15:08, Thomas Eliassen wrote:
>
> Is there some way to avoid having it logged as a 500 in the access log then?
At the moment, no. And my preference is to avoid creating new
configuration options unless we have to.
> ClientAbortExceptions are so frequent that it really pollutes the access
> logs, drowns out 500s actually caused by the server side application, and
> makes monitoring and debugging based on the access logging a lot harder.
Fair point.
> I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions.
I've been looking at RFC 7231 in more detail.
None of the status codes are ideal. Of course, they are intended for the
client which in this case is never going to see the status code anyway
but still...
The general description of 2xx codes looks to be appropriate:
"... the client's request was successfully received, understood, and
accepted."
200 doesn't seem right since:
"... the request has succeeded."
202 could be better since:
"... the request has been accepted for processing, but the processing
has not been completed."
but the intention behind 202 is very different so using it in this case
seems wrong.
None of the other 2xx codes seem to be a match at all.
The 4xx codes are another possibility:
"... 4xx (Client Error) class of status code indicates that the client
seems to have erred."
Of those only 400 is a possible match.
"... the server cannot or will not process the request due to something
that is perceived to be a client error."
The 5xx codes are also possible:
"... the server is aware that it has erred or is incapable of performing
the requested method"
With 500 being the best match in that case:
"... the server encountered an unexpected condition that prevented it
from fulfilling the request."
You have already explained why using 500 is a problem. 400 suffers from
a similar issue. Which brings us back to 200 which doesn't seem right
either.
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
>
> --
>
> Another one I failed to send to the list first time around...
>
> On 29/05/17 08:26, Thomas Eliassen wrote:
>> Hi,
>>
>> Since https://bz.apache.org/bugzilla/show_bug.cgi?id=60718 (r1783148 in
>> tc8.5.x), ClientAbortExceptions are logged in the access log as status 500,
>> changed from the previous status 200.
>>
>> Is this actually the desired behaviour? It doesn't seem appropriate to log a
>> 500 as this isn't necessarily a server error.
>
> The server has no way of knowing for sure whether the request processing
> completed cleanly and then failed when the completed response was being
> written or if the exception caused the processing to abort half-way through.
>
> A 200 response certainly doesn't look to be correct.
>
> None of the 4xx codes look to be appropriate.
>
> That does, pretty much, leave the 500 code which does not seem an
> unreasonable option.
>
>> Also, the error isn't being logged to catalina.log using the default
>> logging.properties, which for a 500 error seems wrong.
>
> I suspect if you enable debug logging you'll see it. It doesn't make
> sense to log user triggered exceptions by default.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
