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

Hi Cyrus,

Thanks for the quick feedback.

>
> Some initial comments:
>
> 1) You should define how this interacts with WebDAV ACL. The obvious
solution to that is to say that APPEND and PATCH are controlled in the same
> way as PUT via ACL (i.e. write-content privilege is needed).
>

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.

> 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.

> 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.
>

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.

> 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.

> 10) Its worth pointing out somewhere that the PATCH body can in some
cases
> be larger than the entire modified resource, so in that case a PUT is
better than PATCH. i.e. a client should be smart enough to figure out which
> is better and use that.
>

Yes, I suspect that PUT would be better in some cases even when the PATCH
body is smaller than the resource, but still large enough that the
overhead involved in processing the instructions makes it less efficient.
I am planning to do some performance testing to explore this.

> --
> Cyrus Daboo
>

As I mentioned, I developed a proof-of-concept implementation for these
methods for the mod_dav server and will be doing some performance testing
to see how they compare to the PUT method.

Thanks for pointing these issues. I realize now that they need to be
clarified in the I-D.

-Suma

Received on Friday, 4 August 2006 07:04:52 UTC