W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2005

Re: erratum in RFC 2616: 405 should not require an Allow field in response

From: Yves Lafon <ylafon@w3.org>
Date: Fri, 24 Jun 2005 12:08:06 +0200 (MEST)
To: Alex Rousskov <rousskov@measurement-factory.com>
cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.GSO.4.63.0506241148010.13894@gnenaghyn.vaevn.se>
On Thu, 23 Jun 2005, Alex Rousskov wrote:

> On Thu, 2005-06-23 at 14:00 -0700, Roy T. Fielding wrote:
>> In RFC 2616:
>> 10.4.6 405 Method Not Allowed
>>     The method specified in the Request-Line is not allowed for the
>>     resource identified by the Request-URI. The response MUST include an
>>     Allow header containing a list of valid methods for the requested
>>     resource.
>> which has the effect of requiring that a server advertise all
>> methods to a resource.
> The MUST requirement does not say "a list of ALL valid methods", but
> perhaps that is implied.

Note that in 5.1.1
An origin server SHOULD return the status code 405 (Method Not Allowed) if 
the method is known by the origin server but not allowed for the requested 
resource, and 501 (Not Implemented) if the method is unrecognized or not 
implemented by the origin server.

So if the server needs to hide something to an authenticated requester, it 
may not user 405 but something else (403?)

>>   In some cases, method implementation is
>> implemented across several (extensible) parts of a server and
>> thus not known.  In other cases, it may not be prudent to tell

For this case, how about slightly modifying the definition of Allow in 
14.7 to say that the list of method may be incomplete?

>> an unauthenticated client all of the methods that might be
>> available to other clients.
>> I think the above should be modified to s/MUST/MAY/; does anyone
>> here know of a reason not to make that change?
> RFC 2616 says that "the methods GET and HEAD MUST be supported by all
> general-purpose servers". Thus, a general-purpose server (whatever that
> is) can satisfy the above MUST by listing GET and HEAD in the Allow
> header. Note that unauthorized requests can be denied, if needed.
> Said that, I suspect that changing this MUST to SHOULD or MAY will not
> have a negative impact on implementations.

Indeed, but it does not prevent fixing other parts of the RFC as well.

Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."
Received on Friday, 24 June 2005 10:11:07 UTC

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