https://issues.apache.org/bugzilla/show_bug.cgi?id=56555
--- Comment #3 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Brett from comment #0)
> Background/Expected Behavior:
> Our application is a RESTful web service, we return error responses with
> status code 400 in situations, like for example when a POST to access a
> request token contains a valid username but invalid password.
Shouldn't this be 403?
(In reply to Brett from comment #2)
> Thanks for the quick reply. So is it expected behavior, even in cases where
> "Connection: keep-alive" is set, for the container to force it to
> "Connection: close"?
Not generally, but "400 Bad Request" is kind of a killer. Tomcat defines a few
deal-breaker status codes that will close the connection regardless of the
wishes of the application. You can find them in the statusDropsConnection
method called by the code you already posted. Here's the meat of the method:
return status == 400 /* SC_BAD_REQUEST */ ||
status == 408 /* SC_REQUEST_TIMEOUT */ ||
status == 411 /* SC_LENGTH_REQUIRED */ ||
status == 413 /* SC_REQUEST_ENTITY_TOO_LARGE */ ||
status == 414 /* SC_REQUEST_URI_TOO_LONG */ ||
status == 500 /* SC_INTERNAL_SERVER_ERROR */ ||
status == 503 /* SC_SERVICE_UNAVAILABLE */ ||
status == 501 /* SC_NOT_IMPLEMENTED */;
Basically, any of those status codes should close the connection. The code docs
say that Apache httpd will do the same thing for those status codes (i.e. drop
the connection), but I see no reference to any spec that requires such
behavior.
One could make the argument that the above list covers too much ground (e.g.
NOT IMPLEMENTED or LENGTH_REQUIRED -- why kill the connection in those cases?)
but for the case of "400 Bad Request", the server (application, actually) is
saying that the request itself is garbled, indicating that something horrible
has happened to the connection (or the client). Closing the connection is
appropriate in this case.
I think if you use a 403 response code (which really makes much more sense in
the case presented above, IMO), then you should avoid this problem and go back
to being able to use keepalives.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
