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

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