W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

Re: What are "appropriate Cache-Control or Expires header fields"

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 14 Oct 2009 20:04:57 +1300
Message-ID: <4AD57819.6090905@qbik.com>
To: Brian Smith <brian@briansmith.org>
CC: 'Mark Nottingham' <mnot@mnot.net>, 'HTTP Working Group' <ietf-http-wg@w3.org>

Brian Smith wrote:
> Mark Nottingham wrote:
>> POST caching is still a work in progress; p6 now accommodates it, but
>> we haven't yet modified the definition of POST itself. Stay tuned...
>> WRT 302 / 307 / 303 -- the use of the term 'cacheable' is cloudy here,
>> but otherwise it's pretty straightforward; are you just looking for
>> them to reference the header definitions or p6 in general?
> The definition of "cacheable" is precise enough (see the definition in Part
> 6), although it is confusing because "cacheable" doesn't imply that a cache
> may actually store (aka cache) it; the request and response also have to
> meet the requirements in Part 6, Section 2.1 (Response Cacheability).
> What I am asking is this: How does a Cache-Control field indicate that an
> otherwise-uncacheable response is cacheable? How does an Expires field
> indicate that an otherwise-cacheable response is cacheable?
Expiry means fresh until, which ties in with freshness part of cache 
philosophy, so Expiry header implies cachability (as long as it is in 
the future).

> If a 302/303/307 response doesn't contain an Expires header or a
> Cache-Control header, then it isn't cacheable. That is clear. But, if the
> response contains *any* Expires header, does that make it cacheable? And, if
> it contains any Cache-Control header, does that make it cacheable? Or, does
> the Cache-Control header have to contain specific values like "public,"
> "s-maxage," "must-revalidate", like is specified in Part 7, Section 3.1?
> And, if so, what are those specific values? The only cache-control directive
> definition that specifically says "cacheable" is "public."
> In my implementation, I take the existence of any Cache-Control or Expires
> field in the response makes the response cacheable.
what about Cache-control: no-store, no-cache ?

I think you need to look at what the actual directives are.  As for 
Expiry, it has to be in the future (relative to Date), else it is stale.

IOW I think the response needs to be treated the same way as any other 
response in terms of evaluation of cache-control for cacheability.

Difference might be in treatment of cache validators, since I don't know 
if you can have an ETag or Last-Modified on something that has no entity.

For instance, not every 200 response is cacheable either (which I think 
was asserted earlier in this thread).



> Cheers,
> Brian
>> On 13/10/2009, at 12:22 PM, Brian Smith wrote:
>>> What, precisely, must the Cache-Control or Expires header fields
>>> contain in order to make a response to a POST, a 302 response,
>>> a 303 response, or a 307 response cacheable? This seems to not
>>> be specified anywhere in the specification.

Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 14 October 2009 07:01:41 UTC

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