- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 02 Mar 2009 16:26:36 +0100
- 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 UTC