Re: PROPOSAL: i24 Requiring Allow in 405 Responses

On Wed, 2008-03-19 at 11:54 +1100, Mark Nottingham wrote:
> I think some change is needed, because the text currently places  
> unclear conformance requirements on servers and clients.

Yes. The correct requirements for Allow should be

Servers SHOULD advertise a correct list of the methods the server want
clients to try to use on the resource.

Clients SHOULD honor what the server says when it says something.

Ofcourse there may be supported methods outside of the advertised set,
but servers SHOULD NOT count on clients probing for such methods.

And ofcourse clients MAY attempt other methods is they have exceptional
reason to believe those methods are in fact supported (i.e. by
out-of-band knowledge or manual override).

The rest of the fuzzy cruft discussed is then more or less automatic
from the requirements being just a SHOULD level requirement, allowing
implementations to diverge from correctness is they absolutely need to.

It does not need to be a MUST level requirement for servers to provide a
relevant list in 405 responses, which is what got this thread started.
Some servers can't. Some servers won't. But implementations not doing so
should carefully consider what this means to clients looking into the
contents of the Allow header and assume responsibility if their
implementation causes problems to clients trying to make use of the
information and therefore a SHOULD level requirement to provide a
relevant list.


So my proposed change is to just change "MUST include an Allow header"
to SHOULD in both "Allow" and "405 Method Not Allowed", and leave the
rest as it is.


While at it I would also recommend lowering the proxy rewrite
requirement in "Allow" to SHOULD NOT (currently a MUST NOT), or restrict
it to "A transparent proxy ...". That's another MUST level requirement
which doesn't really make sense in this context.


I would not go into the fuzzy land of "need not be complete" etc. Such
decisions is best left to implementers and only confuses matters further
I think. 

Regards
Henrik

Received on Wednesday, 19 March 2008 23:22:22 UTC