Re: i24: Requiring Allow in 405 responses

Mark Nottingham wrote:
> Exactly. We're not here to re-design Allow or come up with a better 
> mechanism; just to clarify what it means today.
> 
> To reiterate, my proposal:
> 
>> "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."
> 
> Some will argue that that's loosening the requirements of 2616; I don't 
> think I buy that, because there isn't a RFC2119-level requirement about 
> the contents of the header.

I have to disagree. The absence of a RFC2119-level requirement does not 
mean that something isn't a requirement.

RFC 2616 states:

"The Allow entity-header field lists the set of methods supported by the 
resource identified by the Request-URI."

That's what it means, no matter whether it says or doesn't say "SHOULD" 
or "MUST".

So yes, we are changing a requirement. And yes, we may have to do that 
to reflect reality, but in this case, we'll have to consider the effect 
of that change.

Therefore, if we allow the server not to include all methods, we also 
have to allow a client not to believe what it got, thus:

"However, the indications given by the Allow header field value SHOULD 
be followed."

should be dropped then.

> Thinking about the subsequent discussion, I'm ambivalent about adding a 
> SHOULD-level requirement on the server side WRT completeness; I think 
> the text above stands on its own.
> ...

BR, Julian

Received on Monday, 3 March 2008 08:19:34 UTC