- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Fri, 9 Jul 2004 10:24:06 -0700
- To: Scott Lawrence <scott@skrb.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Jamie Lokier <jamie@shareable.org>, ietf-http-wg@w3.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. Lisa 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