- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 21 Oct 2010 09:13:16 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 21/10/2010, at 3:12 AM, Julian Reschke wrote: >>>> >>>> New methods SHOULD explain how conditional request headers [ref] affect the response (if there is any effect). >>> >>> Wow. I always thought they apply to any method; thus extensions methods can't be special. Maybe this deserves a separate issue? >> >> Well, we could say that 304 is specific to GET/HEAD, and all other methods use 412 for failed conditions, but that bit of glue seems to be missing ATM. >> >> We should probably also warn that clients can't take it for granted that a resource will support conditional requests (if we don't already); this can be surprising if you're expecting it on POST/PUT, etc. >> >> It sounds like we should remove this sentence and open two new issues. > > Hm. > > Are we aware of any implementations that do PUT but do not handle If-Match? That would be surprising. First one I looked at (and used, many moons ago): <http://perso.ec-lyon.fr/lyonel.vincent/apache/mod_put.html> AFAICT nothing requires implementation of If-Match et al when using PUT. Likewise, conditional requests are almost universally UNsupported for POST. > >>>> HTTP methods SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension. >>> >>> That's very vague (what does "other use" mean). >> >> That can be dropped. > > Maybe we should think of applications whether extensions? Authoring/Querying calendar data (CalDAV) would qualify as application, while things like namespace operations (WebDAV COPY/MOVE) or partial updates (PATCH) would be considered extensions. Right. I think that's what we're trying to encourage. >>> Maybe we should start with examples, and then come up with guidelines? >>> >>> - PATCH (RFC 5789) is certainly a good example for a generic definition. >>> >>> - MKCALENDAR (RFC 4791) is certainly a good example for something that shouldn't have been a separate method. >>> >>> I think most of us agree on the above. But what about things between these extremes, such as WebDAV? >> >> >> What this is saying is that the WebDAV methods should have been registered in a non-WebDAV specific document, to clarify that they can be used in other contexts. > > If you take out the message definitions from WebDAV, little will be left. Really. > > COPY/MOVE does require some understanding of collections. PROPFIND/PROPPATCH does require some understanding of metadata. LOCK/UNLOCK does require some understanding of locking semantics. COPY and MOVE don't necessarily require understanding of collections, if you're not using WebDAV. PROPFIND and PROPATCH require understanding of a non-HTTP metadata system, which is probably why they feel so wrong. LOCK and UNLOCK don't necessarily require understand of locking semantics that are specific to WebDAV, do they? > That's why I'm very nervous about making this a hard requirement; what it should be is a recommendation to make methods re-usable, and a reminder for the Expert Reviewers to check this. I think that's the direction we're headed in here... -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 20 October 2010 22:13:53 UTC