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: Mark Nottingham <mnot@mnot.net>
Date: Tue, 3 Mar 2009 18:02:48 +1100
Cc: "Roy T. Fielding" <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <21D7FC1D-D1A5-4FC7-BE2E-592C495DA0CB@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

On 03/03/2009, at 2:26 AM, Julian Reschke wrote:

> 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.

Assuming that that would be in the context of 201 Created, it seems  
reasonable to bring it to HTTP.

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

Seems editorial to me.

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 3 March 2009 07:03:32 UTC

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