Is there some way to avoid having it logged as a 500 in the access log then?
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. I'll also note that e.g. Jetty logs a 200 on ClientAbortExceptions. -- 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
