Re: [squid-users] Expires: vs. Cache-Control: max-age

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_at_semihuman.com]
>> Sent: Freitag, 26. September 2008 23:46
>> To: Squid Users
>> Subject: [squid-users] 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_at_yahoo-inc.com