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

On 14/10/2009, at 5:51 PM, Brian Smith wrote:

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

By giving it an explicit freshness lifetime, as per p6 2.3.


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

Currently, the interpretation is that status code doesn't figure into  
whether something can be stored (as per the other thread), but it does  
figure into whether something can be served heuristically (i.e.,  
without an assigned explicit freshness lifetime).


> 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."

See above.


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

Received on Wednesday, 14 October 2009 07:04:04 UTC