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

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