Search squid archive

Re: Expires: vs. Cache-Control: max-age

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2008-10-01 at 15:42 +1000, Mark Nottingham wrote:
> No, that's not true. RFC2616:
> 
> > 13.2.4 Expiration Calculations
> > In order to decide whether a response is fresh or stale, we need to  
> > compare its freshness lifetime to its age. The age is calculated as  
> > described in section 13.2.3; this section describes how to calculate  
> > the freshness lifetime, and to determine if a response has expired.  
> > In the discussion below, the values can be represented in any form  
> > appropriate for arithmetic operations.
> >
> > We use the term "expires_value" to denote the value of the Expires  
> > header. We use the term "max_age_value" to denote an appropriate  
> > value of the number of seconds carried by the "max-age" directive of  
> > the Cache-Control header in a response (see section 14.9.3).
> >
> > The max-age directive takes priority over Expires, so if max-age is  
> > present in a response, the calculation is simply:
> >
> > freshness_lifetime = max_age_value
> > Otherwise, if Expires is present in the response, the calculation is:
> >
> > freshness_lifetime = expires_value - date_value
> 
> and later:
> 
> > 14.9.3 Modifications of the Basic Expiration Mechanism
> > The expiration time of an entity MAY be specified by the origin  
> > server using the Expires header (see section 14.21). Alternatively,  
> > it MAY be specified using the max-age directive in a response. When  
> > the max-age cache-control directive is present in a cached response,  
> > the response is stale if its current age is greater than the age  
> > value given (in seconds) at the time of a new request for that  
> > resource. The max-age directive on a response implies that the  
> > response is cacheable (i.e., "public") unless some other, more  
> > restrictive cache directive is also present.
> >
> > If a response includes both an Expires header and a max-age  
> > directive, the max-age directive overrides the Expires header, even  
> > if the Expires header is more restrictive. This rule allows an  
> > origin server to provide, for a given response, a longer expiration  
> > time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This  
> > might be useful if certain HTTP/1.0 caches improperly calculate ages  
> > or expiration times, perhaps due to desynchronized clocks.
> >
> 
> I.e., the max-age cache-control directive takes precedence over Expires.
> I've tested Squid and a number of other caches with Co-Advisor, and if  
> Expires indicates the response is fresh, but CC: max-age says it's  
> stale, it will treat it as stale, for just about any given cache.  
> Unfortunately, Co-Advisor doesn't test the reverse situation, although  
> I may have overlooked it (Alex?).

I am sorry, I am not sure what you mean by the "reverse situation".
Expires indicates stale but max-age says fresh? If not, can you specify
it explicitly?

Thank you,

Alex.


> On 27/09/2008, at 4:44 PM, Markus Karg wrote:
> 
> > According to HTTP/1.1 specification, the precedence is not  
> > determined by
> > the keyword, but by the value: The shorter age is to be taken.
> >
> > Regards
> > Markus
> >
> >> -----Original Message-----
> >> From: Chris Woodfield [mailto:rekoil@xxxxxxxxxxxxx]
> >> Sent: Freitag, 26. September 2008 23:46
> >> To: Squid Users
> >> Subject:  Expires: vs. Cache-Control: max-age
> >>
> >> Hi,
> >>
> >> Can someone confirm whether Expires: or Cache-control: max-age
> >> parameters take precedence when both are present in an object's
> >> headers? My assumption would be Cache-control: max-age would be
> >> preferred, but we're seeing some behavior that suggests otherwise.
> >>
> >> Specifically, we're seeing Expires: headers in the past resulting in
> >> refresh checks against our origin even when a Cache-Control: max-age
> >> header is present and the cached object should be fresh per that
> >> metric.
> >>
> >> What we're seeing is somewhat similar to bug 2430, but I want to make
> >> sure what we're seeing isn't expected behavior.
> >>
> >> Thanks,
> >>
> >> -Chris
> 
> --
> Mark Nottingham       mnot@xxxxxxxxxxxxx
> 


[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux