W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

Re: Clarifying Content-Location for POST/PUT/other methods, was: Cache key history (see also issue 136)

From: Thomas Broyer <t.broyer@gmail.com>
Date: Mon, 2 Mar 2009 17:00:10 +0100
Message-ID: <a9699fd20903020800r1229ee84hd191cf83a3d6cbc5@mail.gmail.com>
To: ietf-http-wg@w3.org
On Mon, Mar 2, 2009 at 4:26 PM, Julian Reschke wrote:
>
> There's also a related issue about the current description of
> Content-Location, see
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/136>.

Yikes! Seems like RFC 2068 did a better job at specifying it than RFC
2616. Specifically, that last sentence that you didn't understand 4
months ago is the one defining the behavior that Roy described (and
that we then put in Atom):

"In addition, a server SHOULD provide a Content-Location for the
resource corresponding to the response entity."

When the request is *not* a GET, the response entity is not by
definition a representation of the resource identified by the
request-URI. If it is the representation of an "addressable" resource,
the server SHOULD provide a Content-Location for that resource (that's
the behavior described in AtomPub, if Content-Location matches
Location, it means the response entity is a representation of the
newly created resource). And in case the response entity is a
representation of the resource identified by the request-URI, the
Content-Location value will be the request-URI (same thing, in
response to, e.g., PUT requests).

AtomPub actually adds the constraint that the returned representation
is a "complete representation" of the resource; and tells server to
use character-for-character equal values for Location and
Content-Location (notably because Content-Location allows a relative
URL while Location mandates an absolute reference).


-- 
Thomas Broyer
Received on Monday, 2 March 2009 16:00:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT