- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 28 Feb 2008 09:47:11 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote: > ... > * There is no existing normative text for (b); OPTIONS lists Allow as an > example, nothing more AFAICT. Expanding it to a SHOULD or MUST seems too > aggressive, and software that depends upon it today is already taking > liberties (unless a specific overlay protocol like WebDAV specifies > otherwise). > ... 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." So it seems to me that is really *is* a SHOULD level requirement for include "Allow". > ... > "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. BR, Julian
Received on Thursday, 28 February 2008 08:47:31 UTC