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: Tue, 4 Mar 2008 09:25:18 -0800
Message-Id: <845370F4-5366-4ABD-B1A8-A592962CCB97@gbiv.com>
Cc: John Kemp <john@jkemp.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>

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.

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.

....Roy
Received on Tuesday, 4 March 2008 17:25:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT