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

Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 21 Mar 2008 08:44:44 +1100
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>
Message-Id: <59E3FDA6-5956-4629-960B-216E8EF2E1A3@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT