- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 4 Mar 2008 09:25:18 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: John Kemp <john@jkemp.net>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC