Subject: Re: Cache key history

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Mar 2009 16:48:58 +1100

Catching up on this...

I think we're not actually that far apart, then.

People want POSTs to be reusable for GETs, and you appear to be saying  
that if we properly specify what it means for POST to be cacheable,  
and more importantly under what conditions something cached by POST  
can be reused, this is possible.

As such, we need to both document the requirements for what it means  
to call a method cacheable, and also better document what it means for  
POST to be cacheable. The same is true of GET, but hopefully that's a  
little more obvious...

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.

Make sense, or have I misinterpreted something?

Cheers,

On 02/12/2008, at 12:37 PM, Roy T. Fielding wrote:

>
> On Nov 28, 2008, at 2:41 PM, Mark Nottingham wrote:
>
>> When the cache key discussion came up, it became clear that we  
>> needed to do some digging into the history of HTTP caching, which  
>> means looking at the mailing list of the original HTTPWG's caching  
>> sub-group. Unfortunately, I couldn't locate any online archives  
>> remaining, but Martin Hamilton kindly provided an mbox, which has  
>> been reconstructed at:
>>
>> http://lists.w3.org/Archives/Public/http-caching-historical/
>>
>> In looking through that, it's clear that there was discussion of  
>> POST caching, etc. early on;
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Jan/0025.html
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Jan/0026.html
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Jan/0028.html
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Jan/0030.html
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Jan/0075.html
>>
>> (I believe this is before the difference between Location and  
>> Content-Location was specified, which is why Location is mentioned).
>>
>> But, no consensus was reached, as reflected by the state of the  
>> "updated issues list" (under "not agreed");
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Feb/0114.html
>>
>> It did come up at a F2F, but was not "fully" discussed, and several  
>> aspects were deferred;
>>  http://lists.w3.org/Archives/Public/http-caching-historical/1996Feb/0039.html
>
> I addressed the relevant parts of that meeting (which I was not able
> to attend in person) in this post:
>
> <http://lists.w3.org/Archives/Public/http-caching-historical/1996Feb/0095.html 
> >
>
> The question boils down to the three cache models under Extensibility:
>
> > Larry described possible three ways to view an HTTP cache:
> >
> > 	a) a cache stores values and performs operations on these
> > 	values based on the requests and responses it sees.  For
> > 	the purposes of the cache, one can describe each HTTP
> > 	method as a transformation on the values of one or more
> > 	resources.
> > 	
> > 	b) a cache stores responses, period.
> > 	
> > 	c) a cache stores the responses to specific requests.
> > 	The cache must be cognizant of the potential interactions
> > 	between various requests; for example, a PUT on a resource
> > 	should somehow invalidate the cached result of a previous
> > 	GET on the same resources, but a POST on that resource
> > 	might not invalidate the result of the GET.
>
> The HTTP/1.1 proposal that Henrik and I developed was based on (c).
> HTTP is supposed to be more extensible than a storage interface.
> Our design decision was to make the messages self-descriptive
> rather than assume a prescriptive data model, thereby allowing
> efficient cache operation via message description on arbitrary
> methods.  It was a known trade-off versus the more traditional
> caching models of distributed file systems that could benefit
> from write-back caching by limiting the set and scope of
> resource-modifying operations to a shared data model.
>
> Rough consensus in both the WG and implementations was on (c), but
> that was not entirely reflected in the caching section that was
> added to the pre-2068 spec during the final revs.  The caching
> section left it out. The rest of the HTTP spec is based on (c).
> The visible difference between (a) and (c) is how cacheable
> responses to non-GET requests are enabled, which is defined in
> model (c) by the method semantics, response status code, and
> the response field-values for Cache-Control and Content-Location.
> It was not successfully defined by model (a).
>
> In other words, an HTTP cache must consider the method as part
> of the cache key if it allows caching of anything other than
> GET/HEAD responses.  An HTTP cache cannot do write-back operations.
> A response to a non-GET/HEAD request is cacheable if it says so
> in cache-control *and* the cache understands how to construct
> the cache key for that method (this is presumed to be defined by
> the method semantics). Any response that contains a Content-Location
> is cacheable as if it were a 200 response to GET if it can be
> trusted to be from the same authority as that location value.
> It follows, therefore, that a response to POST that includes
> both a cacheable Cache-Control and a Content-Location matching
> the POST request target is equivalent to saying that the enclosed
> entity contains what would be in the response to a GET on that
> same URI immediately after the POST completed.
>
> The HTTP/1.1 proposal was not designed to behave like a storage
> interface, so it's no surprise that it doesn't look like a CPU
> cache or even a disk cache.  Jeff tried to address that issue in
> his summary of the cache models.  I think that the subgroup
> discussion showed that model (a) did not fit the needs of HTTP.
> The subgroup's operating procedures at the time were that the
> existing HTTP/1.1 design would not be changed unless there was
> rough consensus for the change.
>
> ....Roy
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Mar 2009 16:26:36 +0100

Mark Nottingham wrote:
> ...
> ...

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

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 2 Mar 2009 17:00:10 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/136>.

Yikes! Seems like RFC 2068 did a better job at specifying it than RFC
2616. Specifically, that last sentence that you didn't understand 4
months ago is the one defining the behavior that Roy described (and
that we then put in Atom):

"In addition, a server SHOULD provide a Content-Location for the
resource corresponding to the response entity."

When the request is *not* a GET, the response entity is not by
definition a representation of the resource identified by the
request-URI. If it is the representation of an "addressable" resource,
the server SHOULD provide a Content-Location for that resource (that's
the behavior described in AtomPub, if Content-Location matches
Location, it means the response entity is a representation of the
newly created resource). And in case the response entity is a
representation of the resource identified by the request-URI, the
Content-Location value will be the request-URI (same thing, in
response to, e.g., PUT requests).

AtomPub actually adds the constraint that the returned representation
is a "complete representation" of the resource; and tells server to
use character-for-character equal values for Location and
Content-Location (notably because Content-Location allows a relative
URL while Location mandates an absolute reference).

-- 
Thomas Broyer

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Mar 2009 18:02:48 +1100

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

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

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

> Content-Location, see <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/136 
> >.

Seems editorial to me.