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

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_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
>
Received on Thu Oct 02 2008 - 05:37:46 MDT