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

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 02 Mar 2009 16:26:36 +0100
Message-ID: <49ABFAAC.1000907@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Mark Nottingham wrote:
> ...
> However, you've said a few times that a POST response has to have a 
> Content-Location to be considered cacheable. That's not documented 
> anywhere, of course, and while it's one thing we could specify when we 
> properly document POST cacheability, we should discuss this first.
> ...

That would be great; we really should clarify whether the related text 
in AtomPub:

"If the creation request contained an Atom Entry Document, and the 
subsequent response from the server contains a Content-Location header 
that matches the Location header character-for-character, then the 
client is authorized to interpret the response entity as being a 
complete representation of the newly created Entry. Without a matching 
Content-Location header, the client MUST NOT assume the returned entity 
is a complete representation of the created Resource." -- 
<http://greenbytes.de/tech/webdav/rfc5023.html#rfc.section.9.2.p.4>

is specific to AtomPub, or applies to HTTP in general.

There's also a related issue about the current description of 
Content-Location, see 
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/136>.

BR, Julian
Received on Monday, 2 March 2009 15:27:21 GMT

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