Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
The inconsistency stems from the different status codes used. If TRACE is
disabled at the connector, level then a 405 is returned for TRACE requests. If
readOnly is set in the DefaultServlet, a 403 is returned for PUT and DELETE.
Methods that return a 405 should not be included in an OPTIONS response.
Doing some mailing list archaeology, the readOnly parameter started out in
the WebDAV servlet ( http://markmail.org/message/vls7an5nhf7eigwc ) and was
refactored to the Default Servlet shortly afterwards (
http://markmail.org/message/vls7an5nhf7eigwc ). All this was back in 2000.
Looking at RFC 2616 (since this code pre-dates RFC7231) there isn't much to
choose between 403 and 405. Both look equally applicable. One obvious
difference for this use case is that a 405 MUST include an Allow header so on
that basis using 403 looks to be the simpler implementation.
RFC 7231 adds some detail on the differences between 403 and 405. In short
405 means 'method never allowed' whereas 403 means 'request not allowed but
might be allowed with different credentials'.
In this case it is arguable that 405 is the better response code since if
readOnly is true, PUT and DELETE are never going to be allowed (with a similar
argument applied to many of the WebDAV methods). We have made changes in 9.0.x
to better align with RFC 7231 so I'm not against considering changing the
status code used. That would also mean changing the OPTIONS response.
As I have been researching this I noticed that the is scope to clean up the
existing code. HttpServlet.doOptions() could use a StringBuilder and
ALLOW_OPTIONS seems unnecessary. DefaultServlet.doOptions() appears to be
unnecessary as well. This clean-up assumes the current behaviour is not
changed. A switch to using 405 is likely to impact some of that clean-up.
If there is interest in switching the DefaultServlet to use 405 rather than
403 when readOnly is true, I'd suggest that a discussion on the dev@ list is
required to ensure there is consensus on this approach.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
