W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

Re: Location Proposals

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 2 Sep 1995 23:50:14 +0200 (MET DST)
Message-Id: <199509022150.XAA06991@wswiop05.win.tue.nl>
To: Shel Kaphan <sjk@amazon.com>
Cc: koen@win.tue.nl, sjk@amazon.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel Kaphan:
>At time T1 + 1 hour, the client re-requests the document, the cache is
>now up, and so the cache delivers the older copy.  Now, since the
>cached document had not *expired*, you could say this is fine,

Yes, I say this is fine.

> and I don't
>have any idea how this could be avoided anyhow.

Nor do I.  That is why it want to define it as being allowed to

>  But the user could easily
>notice that they were now seeing an older copy of a document they once
>had a newer copy of.

Yes.  But if the service author thinks that users will be terminally
confused when noticing this, the service author can prevent it from
ever happening by putting Expires: <yesterday> headers in the

> > You are still thinking in terms of a mechanism that makes caches
> > replace previously cached, but unexpired, copies.
>They sure should do so!  If a cache gets a newer copy of a document,
>it should lose the older one, even if its not expired.  Is this

Yes it is controversial.  The spec currently says that 

  not expired = OK to show ,

and I don't want to change this simple rule.  Losing older, but
un-expired, responses is nice behavior, but it should be *optional*
behavior.  Else, we get either huge robustness problems or huge
efficiency problems.

>  Expiration dates are a very weird concept anyway.
>We're mostly using them to signal that something is "pre-expired" and
>so uncacheable, something best done with some other mechanism anyway.

Well, we have Cache-Control now, which seems to be completely
equivalent to Expires, so you can use that.

>A cache can never know whether a
>document has been more recently modified than the last time it fetched it.
>So it has to check every time.

I don't want it to check every time: the spec does not (and should
not) require it to do so.  If I put

  Expires: Mon, 01 Jan 2001 00:00:00 GMT

on a frequently used inline picture on my busy web site (say it is
used 100 times every second, because it is inlined on every page on my
site), the last thing I want is to get 100 conditional GETs on this
picture a second!


Received on Saturday, 2 September 1995 14:52:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC