W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2004

Re: FYI: I-D ACTION:draft-dusseault-http-patch-02.txt

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 9 Jul 2004 10:24:06 -0700
Message-Id: <C7DB3ED2-D1CC-11D8-B746-000A95B2BB72@osafoundation.org>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Jamie Lokier <jamie@shareable.org>, ietf-http-wg@w3.org
To: Scott Lawrence <scott@skrb.org>

That could be reasonable for as-yet-undefined patch formats, but I'd 
like at least one patch format to work "out-of-the-box" with the PATCH 
proposal -- a single generic patch format that doesn't need an 
additional specification in order to know how to use it.  If that's 
gdiff (my current thought), then the spec would have to say what the 
server should do when receiving a PATCH request with a gdiff body to an 
unmapped URL.  Perhaps it's sufficient for the spec to say that for 
gdiff, this should fail, because it's not clear what MIME type resource 
to create.


On Jul 9, 2004, at 9:56 AM, Scott Lawrence wrote:

> On Fri, 2004-07-09 at 12:42, Lisa Dusseault wrote:
>> As you point out, not all deltas apply to all formats.  That makes it
>> harder for the server to create an empty representation to patch.  How
>> would it work for, say, GDIFF?  What kind of file would the server
>> create?  Would it be a text/plain file or some other MIME type?
> Ultimately, servers are going to have to choose a patch application
> method based on the content-type of the PATCH content.  That method 
> will
> know what it can patch, and will have to indicate an error should it be
> applied inappropriately - empty or non-existent resources are edge 
> cases
> that don't need to be discussed at all in the description of PATCH.
> -- 
> Scott Lawrence
Received on Friday, 9 July 2004 13:24:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:25 UTC