Re: I-D for WebDAV methods - APPEND and PATCH
Julian Reschke <julian.reschke <at> gmx.de>
2006-08-04 07:37:31 GMT
Suma Potluri schrieb:
> 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
That's correct, and it's completely OK to start a new take on getting
this method defined. It's just that there is a lot of useful discussion
in these email threads.
> 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
General remark: I think it's not a good idea to base this on WebDAV.
This is a generic HTTP problem, and if the solution depends on WebDAV in
any way, that's problematic. On the other hand, it would be ok to have
appendices discussing on how these messages relate to WebDAV, versioning
> 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.
You simply have to do that. RFC2616 *mandates* that when you send an
HTTP message, the Content-Type header defines the type of the content.
That's what it's for.
> 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.
True. Again, the method definition should just state that the path
format is defined in the Content-Type header. This gives you all the
extensibility we need (text diff, binary patches...).
The single issue with this spec (that eventually brought the previous
attempt to a halt) is that there seems to be agreement that the spec
should require at least one simple (!) patch format, and that needs to
have a MIME type (either already defined or defined by this spec), and
that needs to satisfy the IPR requirements of the IETF.
> 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.
OK, here's an example:
Instead of saying:
APPEND /~suma/index.txt HTTP/1.1
Hello World Again!!!
PATCH /~suma/index.txt HTTP/1.1
Hello World Again!!!
And then let the spec define the MIME types for "text/entity-append"
(appending to a resource with text/* MIME type) and possibly
> 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.
I understand that the prototype implementation is an essential part of
your project, and it's definitively useful to test it in practice, but
of course proper specification is what the people over here are more
Best regards, Julian