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: Fri, 22 Oct 2010 13:06:34 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <A9552FC9-F87E-408A-A4FC-E84647FD59AC@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
Updated for conversation to date; I removed the language about conditional requests (will open a ticket shortly).



On 22/10/2010, at 3:59 AM, Julian Reschke wrote:

> On 21.10.2010 00:13, Mark Nottingham wrote:
>> ...
>>> 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://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.24>:
> 
> "The If-Match request-header field is used with a method to make it conditional...
> 
> ...If none of the entity tags match, or if "*" is given and no current entity exists, the server MUST NOT perform the requested method, and MUST return a 412 (Precondition Failed) response...."
> 
> That doesn't sound optional to me, but I agree that it's likely many people get this wrong.
> 
> We need to clarify this, and maybe also think about how to discover this (do a test request with a known not-to-match Etag?).
> 
>>>>>> 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.
> 
> "HTTP methods SHOULD be registered in a document that isn't specific to an application (for instance, synchronization of browser settings), so that it's clear that they are of generic use."
> 
> ?
> 
> 
>>>>> 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.
> 
> That's true. So COPY/MOVE could be defined for "plain" resources (only affecting the resource they are applied to), and WebDAV could describe how they word when applied to non-leaf nodes in the WebDAV collection model. (This is a good discussion to have!)
> 
> > PROPFIND and PROPATCH require understanding of a non-HTTP metadata
> > system, which is probably why they feel so wrong.
> 
> Can you defined what a "HTTP metadata" system is?
> 
> We can argue that header fields are sufficient, in which case there'd be no need for PROPPATCH/PROPFIND, unless we want overwrite individual properties, and retrieve only a subset.
> 
> On the other hand, if header fields are *not* sufficient, then a different format is needed, and a way to link resources to their metadata.
> 
> The format used by WebDAV is DAV:prop (no media type though, sigh). The WebDAV way to like metadata to resources is PROPFIND (no link, no adressability through GET).
> 
> So yes, WebDAV got several aspects wrong, but *if* there's a method with PROPFIND-like semantics, it also needs a format for marshaling to be useful.
> 
> > LOCK and UNLOCK don't necessarily require understand of locking
> > semantics that are specific to WebDAV, do they?
> 
> Why would you want to LOCK a resource if you don't know what effect it has?
> 
>>> 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...
> 
> Best regards, Julian

--
Mark Nottingham   http://www.mnot.net/
Received on Friday, 22 October 2010 02:07:19 GMT

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