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

Re: [Fwd: I-D ACTION:draft-dusseault-http-patch-08.txt]

From: Mark Baker <distobj@acm.org>
Date: Wed, 1 Aug 2007 16:45:47 -0400
Message-ID: <e9dffd640708011345t20a73787m6bdabc8950db539@mail.gmail.com>
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org

On 8/1/07, Roy T. Fielding <fielding@gbiv.com> wrote:
> On Aug 1, 2007, at 12:02 PM, Mark Baker wrote:
> > Sure, but if the server wants to signal a successful PATCH, then it's
> > stuck with 2xx.
> >
> > What if, for example, a server wanted to respond to a successful PATCH
> > attempt with a document which revealed (via hyperlinks) a new part of
> > the application?  I've done this with both PUT and POST (mostly POST)
> > in several applications I've developed, so can attest to its utility.
> >
> > What am I missing?  What's the value in restricting the information
> > that a response message can communicate?  What's wrong with just
> > treating a response which communicates the state of the resource
> > post-invocation, as a special case?
> Do you mean indicated by 200 and (Content-Location == Request-URI)?

As a means to indicate the special case, yes, that's what I was
thinking and mentioned to James.  I wasn't aware of the problem you
pointed out below though ...

> Or a new 2xx status code that specifically says the enclosed response
> entity is as if it were a response to GET on the new state?

That would be fine with me.  But earlier you said;

"There is no reason not to define a 200 response to PATCH as being the
same as the representation that would have been received in a GET
response after the patch has been successfully applied"

So to be clear, are you now suggesting that a 200 PATCH response would
*not* have this specific meaning, and that only this new response code
would indicate that it did have it?  If so, great, we're in sync.

>  I would
> prefer a new response code at this point, since experience has shown
> that content-location is difficult to reconstruct in the presence of
> intermediaries.

Interesting, I wasn't aware of that.

Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
Received on Wednesday, 1 August 2007 20:45:52 UTC

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