W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 2006

Re: I-D for WebDAV methods - APPEND and PATCH

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 04 Aug 2006 09:44:29 +0200
Message-ID: <44D2FADD.8060805@gmx.de>
To: Suma Potluri <suma@soe.ucsc.edu>
CC: Cyrus Daboo <cyrus@daboo.name>, w3c-dist-auth@w3.org

Suma Potluri schrieb:
> I agree...I assumed that the behaviour of APPEND and PATCH with regards to
> the WebDAV ACL, Etag, LOCK and the error messages related to a collection
> are the same as the PUT method (Your comments 1, 5, 8 and 9). I will
> clarify this in the I-D.

I wouldn't think it's essential, but a very short appendix probably 
doesn't hurt.

>> 2) You might want to (informatively) reference
>> <http://www.ietf.org/internet-drafts/draft-ietf-simple-xml-patch-ops-02.txt>
> as way of doing XML diffs.
> 
> It is a good idea to add this reference while defining the Patch-Type for
> text/xml resources.

In particular, now would be a good moment to remind the author of that 
draft that a MIME type should be defined :-).

>> 3) Which 'format' of a resource is being patched? With the Accept header
> a
>> client can get resource data from the server in several different
> formats
>> if supported (e.g. text/plain or text/html). It needs to be clear that
> APPEND and PATCH are operating on the 'native' content type of the resource
>> (i.e. the one indicated by the 'getcontenttype' WebDAV property) and not
> on
>> one of the 'derived' types that the client may have retrieved.

Authoring content-negotiated resources is underspecified in HTTP. Common 
wisdom seems to be that the right way to do that is for the server to 
expose the Content-Location header for the variant (in HEAD or GET 
responses), and for clients always to address these in write operations. 
Everything else gets messy.

Anyway, if people want to address this (interesting) problem, please do 
not restrict it to a specific method. It deserves a generic solution, 
working with PUT, DELETE, PROPPATCH and so on...

> Yes.. the 'native' content-type of the resource is to be considered while
> patching and not one of the 'derived' types. I developed a prototype
> implementation for these two methods in the apache mod_dav module for the
> mod_dav_fs repository. And this is exactly what I am doing - checking if
> the content-type returned by the 'getcontenttype' property is supported by
> the corresponding Patch-Type.

I think this is making things more complex than necessary.

>> 7) BTW Is APPEND really needed? Surely a PATCH can do the same thing
> (except that PATCH cannot create a new resource)?
> 
> It is true that PATCH can do the job of APPEND as well. But the APPEND
> method is much simpler and can be applied to any resource without being
> concerned about the resource type and the Patch-Type. Assuming that a
> client need to do mostly appends, this method comes in handy without the
> 'baggage' associated with the PATCH method. Also it is more efficient to
> implement at the server and may have a quicker response time.

I don't see how it's easier to specify or more efficient to execute than 
the format I proposed in my other mail.

> ...

Best regards, Julian
Received on Friday, 4 August 2006 07:44:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:15 GMT