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 >
