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

Re: Patch options -- summary of recent conversations

From: Lisa Dusseault <lisa@osafoundation.org>
Date: Fri, 10 Aug 2007 13:50:03 -0700
Message-Id: <A3A7A130-F3F1-4614-B982-3107DC92F0D0@osafoundation.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
To: James M Snell <jasnell@gmail.com>

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).

Received on Friday, 10 August 2007 20:50:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:43 UTC