Re: i24: Requiring Allow in 405 responses

Mark Nottingham wrote:
> ...
>> Hm. From 
>> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.2.p.6>:
>>
>> "A 200 response SHOULD include any header fields that indicate 
>> optional features implemented by the server and applicable to that 
>> resource (e.g., Allow), possibly including extensions not defined by 
>> this specification."
> 
> My bad - was looking at the wrong section when I wrote that. so, 405 
> MUST, OPTIONS implicit SHOULD.
> 
> 
> 
>> So it seems to me that is really *is* a SHOULD level requirement for 
>> include "Allow".
> 
> Well, it's an example of how to fulfil a SHOULD-level requirement. 
> Almost the same, but not quite.

Let me rephrase that: It's an example of a header that SHOULD be 
included; there may be others not defined in RFC2616. (The "DAV" header 
falls into that category).

>>> ...
>>> "The actual set of allowed methods is defined by the origin server at 
>>> the time of each request."
>>> to
>>> "The actual set of allowed methods is defined by the origin server at 
>>> the time of each request, and may not necessarily include all (or 
>>> any) methods that the server would actually allow in a request if 
>>> presented."
>>> That's my proposal.
>>> ...
>>
>> Me not happy. From 
>> <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7.p.5>:
>>
>> "This field cannot prevent a client from trying other methods. 
>> However, the indications given by the Allow header field value SHOULD 
>> be followed. The actual set of allowed methods is defined by the 
>> origin server at the time of each request."
>>
>> So, if a server returns an incomplete list of methods -- for instance, 
>> not including "PATCH", and the client actually follows *this* 
>> requirement, then it wouldn't even try PATCH.
> 
> It's a SHOULD; there may be legitimate reasons for it not to be followed.

It seems to me it would be unwise to say "clients SHOULD believe the 
Allow header", but "servers MAY leave of methods".

If we relax the requirement for the production, we also need to relax 
the requirement for the recipient.

BR, Julian

Received on Thursday, 28 February 2008 12:26:19 UTC