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

Re: Location Proposals

From: Larry Masinter <masinter@parc.xerox.com>
Date: Thu, 31 Aug 1995 23:26:09 PDT
To: sjk@amazon.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <95Aug31.232623pdt.2763@golden.parc.xerox.com>
> FMI, how do you think that documents with *no* Expires headers should be
> treated by caches?  (Let's posit that they do have valid Last-modified headers).

I think we need to respect the normal way that cache systems work:
User-perceived behavior is identical to what they'd see if the cache
weren't there, except that the performance might be better. The only
assumption is that the server of the data they're caching didn't lie
about 'Expires'.
Caches may save any data, but documents with no Expires headers should
be treated in the same way that Expires yesterday: always be re-tested
with a GET if-modified-since. Caches can assume that servers that
supply data with an 'expires' date in the future didn't lie about the
expires date, whose interpretation is 'this data won't change until
the expires date'.

The expires date only applies to the URL which the data was fetched
*with* and not any other location information that might be supplied.

Some users might want to employ a cache that guesses an 'expires' data
for something that doesn't have one based on the age of the
'last-modified', but I think this behavior is unintuitive and
non-conformal and should be shunned, not reified in the protocol.

People who want to put counters on their pages should note that the
pages won't get cached, response will be slower, users might give up
on their site rather than wait for the silly odometer. Let's not tweak
the protocol around to somehow optimize this case.

Commercial sites that want detailed statistics and click-trails will
either have to wait for applets which can send such data back, or else
put up with 'no caching' or else put up with statistical data
gathering rather than exhaustive data gathering.

Taking this strict interpretation of caching will have only a minimal
impact on the performance of the net, but will greatly improve
reliability over a situation where things get cached for the wrong
reasons, or documents get cached associated with URLs that they
weren't supplied with, etc.

If you want to improve cache behavior, supply meaningful 'expires'
dates. If the server can't guess when the result will change, how
could the user or the cache do a better job?
Received on Thursday, 31 August 1995 23:28:52 UTC

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