Re: #230: Considerations for registering new methods

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

Received on Thursday, 21 October 2010 17:00:28 UTC