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

Re: i24: Requiring Allow in 405 responses

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 14 Feb 2008 10:10:23 -0800
Message-Id: <39628431-AA29-4137-BCA5-79540BF1A1EA@gbiv.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

On Feb 14, 2008, at 5:11 AM, Julian Reschke wrote:

> Julian Reschke wrote:
>> Hm.
>> Sending an incomplete Allow header will affect clients that use  
>> it. WebDAV clients certainly use it to check for features, and I  
>> wouldn't be surprised if some AtomPub clients did as well (to  
>> check for PUT).
>> So it seems it *is* harmful not to send the header, or just to  
>> send an incomplete list.
>>  From a client's p.o.v., given the choice between an incorrect  
>> list and no list at all, I'd prefer the latter, though.
> ...what I said really applies to successful OPTIONS requests, not  
> Allow in 405 response though...

Right -- I was going to say that yesterday but spent it on other things.

Personally, I don't care whether it is a SHOULD or a MAY, but I don't  
of any software that checks the 405 message's Allow field.  I do know  
Apache can't ensure completeness on its own because a method might be
disallowed by one part of the server (access control) even if the
resource is handled by code that might accept any method (e.g., CGI).
We would have to change the CGI interface (or restrict it to known
methods) to satisfy the original requirement.

What we might want to say is that the Allow field MUST be present if the
response comes from the origin server, and MUST NOT be present if the
method was disallowed by some intermediary without contacting the origin
server.  That does provide useful information even when incomplete.

Received on Thursday, 14 February 2008 18:10:38 UTC

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