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: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 1 Aug 2007 12:52:03 -0700
Message-Id: <3BD0928D-F021-4B7F-B7B6-3BDBB079605B@gbiv.com>
Cc: "Lisa Dusseault" <lisa@osafoundation.org>, ietf-http-wg@w3.org
To: Mark Baker <distobj@acm.org>

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

Received on Wednesday, 1 August 2007 19:52:08 UTC

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