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

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

From: Suma Potluri <suma@soe.ucsc.edu>
Date: Fri, 4 Aug 2006 00:05:52 -0700 (PDT)
Message-ID: <2858.>
To: "Julian Reschke" <julian.reschke@gmx.de>
Cc: w3c-dist-auth@w3.org

Hi Julian,

Thanks for your response. I wasn't aware of the earlier draft on PATCH by
Lisa Dusseault when I submitted this latest draft. I admit that I should
have done a little more research into it before submitting the new I-D. In
any case, I noticed that there hasn't been much activity in this area
since the past two years. I would be happy to collaboratively work with
Lisa Dusseault or anyone else that would be interested in these methods,
so that we could get something useful out of this.

As for the earlier discussion on the PATCH method, I have a few

1) There seemed to be an extensive debate about using a new header field
for the patch format. The way I thought it was that there could
potentially be many patch-types with each patch-type working on a set of
content-types (one indicated by the 'getcontenttype' property). So each
patch-type is mapped to a set of content-types that it would work on.
Using the content-type header to indicate the patch-type that would map
against a set of content-types seemed confusing. But as I was reading the
earlier discussion, there were some convincing objections against using a
new header field. If the Content-Type header is the preferred way to
define the patch format, we could proceed with that.

2) I also noticed that one of the earlier suggestions was to use the
normal diff or diff -e as the required patch format for text files which
was what I proposed in the I-D. It is a simple and widely used diff format
that could be easily generated by the clients. For binary files we could
explore the option of using gdiff as the required diff format.

3) APPEND is a simple and efficient method, since there is no need to be
concerned about the patch formats and content-types. For clients that do
mostly appends, this could be very useful. I'd be interested to hear
comments from the client's perspective with regards to using this method
as opposed to the PATCH method.

Also I have been working on the mod_dav server and was able to get a
working implementation for the two methods - APPEND and PATCH according to
the I-D specification. I am planning to do some performance testing to see
how these methods compare to the PUT method. If we could reach an
agreement on the specification, I could change the prototype accordingly
before testing these methods.

Again thanks for your comments,

> Hi Suma,
> there's quite a lot of previous discussion on the HTTP WG mailing list
that you should review, for instance around the thread
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/thread.html#msg4>).
> So I would approach the topic this way:
> - discuss on the HTTP WG mailing list, not here. This is not specific to
> - realize that APPEND is a special case of PATCH,
> - also realize that PATCH itself doesn't need a lot of work. By
> submitting a PATCH request a client asks the server to modify the
existing resource based on the instructions in the message body. Full stop.
> How the message body is to be interpreted depends on it's Content-Type
(so you don't need "Patch-Type" at all). All the spec really needs to
specify is at least one very simply diff format, and a MIME type for it.
> Speaking of which I see use cases for at least two patch formats (one
for textual diffs such as in the Unix diff command output), and one for
modifying parts on binaries (seek/write/etc).
> <http://greenbytes.de/tech/webdav/draft-dusseault-http-patch-04.html> of
the PATCH draft actually used that model, and IMHO it was a mistake to
move away from it. Quite logically, draft 05 it good serious pushback from
Roy Fielding
> (<http://lists.w3.org/Archives/Public/ietf-http-wg/2004OctDec/0011.html>).
> Best regards, Julian
Received on Friday, 4 August 2006 07:06:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:40 UTC