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