W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i24: Requiring Allow in 405 responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 04 Mar 2008 12:18:55 +0100
Message-ID: <47CD301F.6030302@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: Mark Baker <distobj@acm.org>, John Kemp <john@jkemp.net>, HTTP Working Group <ietf-http-wg@w3.org>

Mark Nottingham wrote:
> I'd note that the issue was raised because some people read the phrasing 
> as requiring all possible methods to be sent, and certainly some 
> implementations try to do this; e.g.,
>   http://bugs.php.net/bug.php?id=32561
>   http://oldsite.webdav.org/mod_dav/bugs/index.php3?id=134
> IMO we need to clarify this text so it's unambiguous. I know people 
> would *like* to depend upon the values in Allow as a complete set, but 
> that's not what implementations do, and it's actually very hard to do in 
> any case.

I think we have the following issues:

- spec inconsistency: 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7> says 
"The Allow entity-header field lists the set of methods supported by the 
resource identified by the Request-URI.", while 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.10.4.6> says 
"The response MUST include an Allow header containing a list of valid 
methods for the requested resource."

- wishful thinking: many servers do not get this right, but 
however spec requires clients to trust it: "However, the indications 
given by the Allow header field value SHOULD be followed. "

- confusion between 405 Not Allowed, 501 Not Implemented, and other 
conditions under which a request could be rejected.

> FWIW, I like "the" -> "a"; it's more elegant than my proposal. I'm less 
> convinced that it's necessary / good to loosen the SHOULD on clients; 
> this sort of thing is what SHOULD is for.

That does not work. If we explicitly allow a subset, the header will be 
almost useless. If we also require clients to trust it, it becomes 
totally useless.

BR, Julian
Received on Tuesday, 4 March 2008 11:19:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC