You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2018/10/02 22:04:05 UTC

[Bug 62797] New: Client aborts are being written as 500 instead of 200

https://bz.apache.org/bugzilla/show_bug.cgi?id=62797

            Bug ID: 62797
           Summary: Client aborts are being written as 500 instead of 200
           Product: Tomcat 9
           Version: 9.0.10
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
          Assignee: dev@tomcat.apache.org
          Reporter: zikfat@gmail.com
  Target Milestone: -----

Created attachment 36187
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=36187&action=edit
patch with a potential fix

After upgrading from Tomcat 8.0.36 to 9.0.10 I noticed new 500 errors showing
up in my access logs without any associated exceptions in the application log.
I believe these are caused by clients aborting their connection to the server,
and that the upgrade in Tomcat versions caused the logged status code for these
requests to change from 200 to 500.

Digging through Tomcat history, it looks like bug 60718 introduced an issue
like this in 9.0.0.M18. After the discussion at
https://markmail.org/message/4cxpwmxhtgnrwh7n it was decided that 200s were the
"least bad" status for client aborts. The commit at
https://github.com/apache/tomcat/commit/3b51ec4d35546a0244f4f7c4ec6c57ebfa5dd883
was made to fix this for 9.0.0.M22 by stopping IOExceptions from setting a 500
status code on the response.

When I trace through the code I see the fix from 9.0.0.M22 is preventing the
500 status from being set initially when the server first encounters an error
trying to write to the client, but the 500 status is getting set later (but
still before access log lines are written) as a side-effect of the
ErrorReportValve.

The ErrorReportValve's invoke method has this line:

response.getCoyoteResponse().action(ActionCode.CLOSE_NOW, null)

Which results in the AbstractProcessor.setErrorState method getting called with
a null throwable. This gets past the IOException guard added in 9.0.0.M22 and
sets the 500 status on the response.

Attached is a patch which has ErrorReportValve pass through the Request's
Throwable on that line. In my testing this seems to fix the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62797] Client aborts are being written as 500 instead of 200

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62797

gregk@bluenile.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gregk@bluenile.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[Bug 62797] Client aborts are being written as 500 instead of 200

Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62797

Remy Maucherat <re...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #1 from Remy Maucherat <re...@apache.org> ---
This makes sense to me. The fix will be in 9.0.13, 8.5.35 and 7.0.92.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org