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