- From: Lisa Dusseault <lisa@osafoundation.org>
- Date: Fri, 10 Aug 2007 13:50:03 -0700
- To: James M Snell <jasnell@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Aug 10, 2007, at 10:00 AM, James M Snell wrote:
>
> Or... since patch formats are identified by mime media type, it
> would be
> possible to use POST and allow the server to derive the intention
> of the
> request from the media type.
>
> POST /resource HTTP/1.1
> Content-Type: application/patch
>
> {patch format}
If the server advertises its support for this Content-Type somewhere,
I could imagine this being sufficiently reliable. I'm still a little
worried that the server might respond successfully to a POST request
without treating it as the client desires -- e.g. adding the request
entity to an Atom collection, submitting it to a HTTP "drop-box",
treating it as an alternative body for the resource, or one of the
many things POST might already be used for out there.
I still prefer PATCH as a verb.
>
> Second... there's the question of how to return a representation of
> the
> modified resource.
>
> The first option is to use 200 OK with the Content-Location header.
>
> HTTP/1.1 200 OK
> Content-Location: /resource
> Content-Type: text/plain
>
> {foo}
>
> At issue is whether or not this is unambiguous enough to work and
> whether or not Content-Location will work effectively (Roy pointed out
> the issues with reconstructing Content-Location when intermediaries
> are
> involved).
Don't forget, there's also Content-MD5. That could be used for the
client to check whether the patched resource is exactly what the
client would have gotten with a local application of the delta, or
whether the server did some post-PATCH content mods (reformatting
XML, adding metadata inside resource, etc).
Lisa
Received on Friday, 10 August 2007 20:50:15 UTC