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: Mark Nottingham <mnot@mnot.net>
Date: Thu, 22 Oct 2009 13:52:07 +1100
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <C6101A82-FADB-4B47-A92C-DD36D123DFAE@mnot.net>
To: Brian Smith <brian@briansmith.org>

On 14/10/2009, at 6:38 PM, Brian Smith wrote:

> Mark Nottingham wrote:
>> On 14/10/2009, at 5:51 PM, Brian Smith wrote:
>>> 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?
>> You're conflating "can be stored in a cache" with "can be served from
>> cache". "cacheable" was used for both in 2616, often in a self-
>> conflicting way. What we're currently trying to do is untangle them.
> Gotcha. So, you could just remove all the sentences from Part 2,  
> Section 8
> containing the word "cacheable," because Part 6, section
> (Calculating Heuristic Freshness) already describes the requirements
> precisely. Is that correct? That does make sense to me.
> I think that 201 and 304 responses cannot be stored in cache, ever,  
> because
> they use the ETag header for a different purpose than for supporting
> conditional GET, so you cannot validate them with the origin server.
> Similarly, does it make sense to cache 405 Method Not Allowed  
> responses to
> POST requests, so that they could be returned for a subsequent GET  
> request?
> Similarly, POST responses 411 Length Required, 413 Request Entity  
> Too Large,
> and 415 Unsupported Media Type responses subsequent GET requests.
> Also, 417 Expectation Failed is basically a "hop-by-hop status code"  
> since
> it only makes sense when an unsupported value for a hop-by-hop request
> header field is provided by the cache to the server.

I think I agree. I believe this can be resolved by further  
constraining what can be stored to things that either:
   a) have explicit freshness information present, or
   b) are allowed to have heuristic freshness information applied

Note that (b) includes such responses even if they don't actually have  
heuristic freshness applied to them; in this manner, a cache can still  
store a 200 response with no Expires or CC: max-age (for example).

Effectively, then, the list of status codes that are cacheable is  
derived from the list of those that allow heuristic freshness to be  
used, with the proviso that other status codes can explicitly state  
their store-ability.

Does this make sense?

If so, there are still two open issues here;

  1) Whether a response with an Expires in the past (for example) can  
be stored (as you brought up), and
  2) Whether caches that don't understand a status code can still  
cache it, if it has explicit freshness available

WRT #1, I think they can, because a cache may want to use that stale  
representation as the basis of revalidation in the future.

WRT #2, I think they should be able to, despite the text you quote:

> Finally, note the following statement in Part 2, Section 4: "However,
> applications MUST understand the class of any status code, as  
> indicated by
> the first digit, and treat any unrecognized response as being  
> equivalent to
> the x00 status code of that class, with the exception that an  
> unrecognized
> response MUST NOT be cached." Here, I think "MUST NOT be cached" means
> specifically "MUST NOT be stored in caches." I think Part 6 should  
> mention
> this requirement explicitly.

because there's no reason that a cache has to understand the status  
code, as long as the cache directives are explicit. At any rate, that  
text conflicts with 2616 14.21:

>    The presence of an Expires header field with a date value of some
>    time in the future on a response that otherwise would by default be
>    non-cacheable indicates that the response is cacheable, unless
>    indicated otherwise by a Cache-Control header field (section 14.9).

But we need to discuss this more.


Mark Nottingham     http://www.mnot.net/
Received on Thursday, 22 October 2009 02:52:42 UTC

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