- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Mar 2008 08:44:44 +1100
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: John Kemp <john@jkemp.net>, Brian Smith <brian@briansmith.org>, "'Julian Reschke'" <julian.reschke@gmx.de>, "'Stefan Eissing'" <stefan.eissing@greenbytes.de>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
I'm afraid I disagree (as much as I'd like to see this issue closed quickly). Your suggestion clarifies when an Allow header must/should appear, but does not clarify what it must contain -- although there seems to be an implication that it be 'complete.' As others and myself have pointed out before, that's not realistic. On 20/03/2008, at 10:20 AM, Henrik Nordstrom wrote: > > 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 > > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 20 March 2008 21:45:33 UTC