RE: PROPOSAL: i24 Requiring Allow in 405 Responses

Henrik,

I agree with your interpretation of what SHOULD means. I mostly agree
with you about the server side, but I disagree that the server should
return 403 instead of 405 if it cannot create an accurate Allow header
field. 403 should only be used when none of the more specific status
codes is applicable, or when one of the other status codes would
disclose too much information. If the server is rejecting the request
solely because of the method used, then 405 is the most appropriate. I
would say that the server SHOULD return an Allow header field in its 405
responses if and only if it can accurately list all of the allowed
methods.

I totally disagree with you regarding the client side behavior though:

* The requirements for client processing of 405/Allow do not need to be
stricter than the requirements for client processing of
401/WWW-Authenticate. When the server returns 401/WWW-Authenticate,
there is nothing that says the client cannot submit the request again
unchanged; we rely on common sense there, and we can (and should) rely
on common sense for 405/Allow.

* The SHOULD requirement implies that the client SHOULD maintain state.

* The SHOULD requirement doesn't have any benefit. The server doesn't
benefit because still has to be able to handle requests with methods it
doesn't support.

* Regardless of what the specification says, clients still have to deal
with servers that do not follow the specification. 

Regards,
Brian

Received on Thursday, 20 March 2008 14:33:18 UTC