W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1997

Re: Fact-checking: do any in-service proxy caches ever ignore Expires?

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Mon, 17 Mar 97 16:39:03 PST
Message-Id: <9703180039.AA13302@acetes.pa.dec.com>
To: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2691
I wrote:
    Koen and I have been discussing offline whether it is possible
    to send
	    Expires: Sun, 06 Nov 1994 08:49:37 GMT
    (or some similar ancient date) to ensure that *every* pre-HTTP/1.1
    proxy cache will not, under *any* circumstances, cache the response.

This wasn't a very good way of asking the question (I should have been
a lot more careful about using the verb "to cache").

I should have asked whether sending an old http-date in an Expires header
will ensure that *every* pre-HTTP/1.1 proxy cache will not, under
any* circumstances, use a cached copy of the response in reply to a
subsequent request without first checking with the origin server,
using an "If-Modified-Since" request.

I.e., in HTTP/1.1 terms, will the proxy cache ever knowingly return
an explictly stale response?

I got some responses, not all of which were forwarded to the mailing

Here's what I have been told:

Ari Luotonen
    All various CERN proxy 3.0 versions and all versions of Netscape Proxy
    (1.1, 2.0, 2.5) handle the Expires: header correctly, and understand
    it to mean "do not use without revalidation after this time".
Vinod Valloppillil <vinodv@microsoft.com>
    We [Microsoft] always honor expires: in our proxy server

Dave Ladd (dladd@spyglass.com)
    [SurfWatch ProServer from Sypglass] will cache responses with an 
    explicit Expires, but if the date is in the past, we'll end up
    always trying a conditional get. (Expires only affects the 
    freshness lifetime).

Peter Danzig
    To the best of my recollection, no version of the
    Harvest cache or its derivitives ignored an Expires

but ...
>From Anthony Baxter <arb@connect.com.au>
    squid allows you to force certain pages to not be expired for certain
    amount of time. This is useful for, eg www.realaudio.com, who set all
    their pages to expire 'now' (well, they used to, anyway).
"Kolics Bertold, University of Veszprem" <bertold@tohotom.vein.hu>
    It *is* possible in Squid-1.1.x.
    Excerpt from the Release-Notes:
	"Squid 1.1 switched from a Time-To-Live based expiration model
	to a Refresh-Rate model.  Objects are no longer purged from the
	cache when they expire.  Instead of assigning TTL's when the
	object enters the cache, we now check freshness requirements
	when objects are requested."
    Minimum age can be given for specific URL patterns. By default it is set
    to zero for all URL patterns, but for cache-unfriendly sites it is usually

So I am still a little confused about whether Squid simply lets stuff
stay in the cache past the Expires time, or whether it always checks
past-Expires responses with the origin server before providing them.
Kolics Bertold's quote from the Squid 1.1 release notes implies (but
does not specifically state) that Squid *always* checks freshness;
Anthony Baxter's comments implies (but not specifically state) the

Sorry about the confusing language the first time I sent this.

Received on Monday, 17 March 1997 16:43:52 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC