W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: #230: Considerations for registering new methods

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 21 Oct 2010 09:13:16 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <82386432-D640-41FE-84C8-198945C6762D@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

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 GMT

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