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

Re: PROPOSAL: i24 Requiring Allow in 405 Responses

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 20 Mar 2008 15:21:12 +0100
Message-ID: <47E272D8.7050606@gmx.de>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
CC: Mark Nottingham <mnot@mnot.net>, John Kemp <john@jkemp.net>, Brian Smith <brian@briansmith.org>, 'Stefan Eissing' <stefan.eissing@greenbytes.de>, 'HTTP Working Group' <ietf-http-wg@w3.org>

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.

RFC2616 says "MUST" advertise (in 405 responses). I think the concern is 
that if we relax this to "SHOULD", clients that rely on the presence of 
the header will break. That is, break in a more fatal way as if the 
header is there but incomplete.

Note this is already only a "SHOULD" for the OPTIONS responses. As far 
as I understand, the "Allow on OPTIONS" is the thing clients are really 
interested in, not "Allow on 405".

(I still have a really hard time understanding why a server ever would 
be able to state "405 Not Allowed", but not be able to say what would be 
allowed. Note that 405 != 501.)

Anyway: do we have any evidence of

1) clients failing in *absence* of Allow in a 405 response, and

2) servers failing to return Allow in a 405 response?

(Henrik, can you check logs...?)

If we have evidence for 1) (which I really doubt), we probably need to 
stick with the MUST.

If we have evidence for 2) (which wouldn't surprise me), we probably can 
relax it to SHOULD, as proposed by Henrik.

If we have evidence for both, I'd recommend that we put this issue back 
on the stack of open issues, and try to make progress somewhere else :-)

BR, Julian
Received on Thursday, 20 March 2008 14:22:04 UTC

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