Re: i24: Requiring Allow in 405 responses

Roy T. Fielding wrote:
> Let me reiterate.  What 2616 says on this issue is irrelevant because we
> all know that no implementation behaves the way that 2616 suggests, no
> matter how the sentence is parsed. Therefore, arguing over the exact
> meaning of the existing phrasing is a waste of time.

(I wrote an implementation which I believe does what RFC2616 says; not 
that this would be relevant, but anyway).

> Backwards compatibility is NOT about retaining consistency between
> a document that nobody reads and a new document that we hope people do.
> It is about specifying the protocol so that it corresponds to what
> existing implementations accept and what new implementations should
> implement in order to operate with both new and existing
> implementations of HTTP.
> 
> After the definition of Allow is rephrased to correspond to existing
> practice and the false requirements are removed, then we can talk about
> the exact wording of the true requirements (if any).
> 
> The only current usage of Allow that I know of is in the response to
> OPTIONS and in the response to 405, and in both cases it includes the
> list of methods believed to be allowed at the time of that request by
> the resource handler (which may or may not be aware of all possible
> methods).  No client that I know of depends on the list being 100%
> complete, though at least some webdav clients will look for their
> favorite methods in the list.  Indeed, all that matters is that the
> field contains the list of methods that the server wants to provide
> to the user agent, regardless of why they want to provide it and
> regardless of its completeness.
>
> If anyone knows of specific examples that differ from the above,
> please let us know.

No, I would think this is correct.

So how would this translate into specification text?

BR, Julian

Received on Tuesday, 4 March 2008 17:32:46 UTC