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

Re: Location Proposals

From: Koen Holtman <koen@win.tue.nl>
Date: Fri, 1 Sep 1995 00:21:31 +0200 (MET DST)
Message-Id: <199508312221.AAA05802@wswiop05.win.tue.nl>
To: Shel Kaphan <sjk@amazon.com>
Cc: koen@win.tue.nl, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Shel Kaphan:
>If there is a real possibility that caches would fail to update, or at
>least invalidate (which would be almost as good), items in their
>caches as a result of receiving Location headers, then I am forced to
>agree with you -- certain kinds of pages just have to be completely
>uncacheable.  :(.  

Yes.  But keep in mind that, with conditional GETs, there is a
difference between `this page is not cacheable (has Pragma: no-cache
or Expires <yesterday>' and `this page cannot be served faster/cheaper
the next time using a proxy cache'.

If a response is not (or no longer) cacheable, this does not mean that
a cache is required to throw it away.  If only means that the cache
may not serve the response without first contacting the origin server
(preferably with a conditional GET).  If the conditional GET returns a
`not modified' code, the (expired) response in the cache memory may be
passed on to the client, and bandwidth is saved.

>At this point, using Location would just be introducing a very slight
>bandwidth saving -- so slight as to hardly be worth the trouble, I
>think.

As caches can safely ignore Location headers on POST responses (under
my scheme), there is no real disadvantage to putting this type of
Location header use in the spec.  Bandwidth saving has to wait until
conditional GETs become more common.  (Has anyone implemented them
now?)

>The case of the cache that goes down for a while, and comes up holding
>now-invalidated copies of things without knowing it, seems to apply
>more generally than to just this case, however.

Under the current spec, going down and coming up without clearing the
cache database is safe (assuming a reasonable implementation that
keeps absolute time stamps in the database, and always checks these
time stamps before serving a response from cache).

If a cache comes up again after 100 days, it will simply find that
most of the `expires after' timestamps on its cache slots hold dates
more than 90 days before the current time.  No problem.

[..in other message..]

>Now you've got me worried.  The example you gave requires that your
>"basket" page never be cached, essentially because it is accessed
>under different URIs for different request methods,

No.  Essentially, it cannot be cached because it is dynamic, because
it may change 1 second from now.

And again, note that `cannot be cached' does not mean that a cache may
not store it.

> and caches in the
>world can't be assumed to be continuously up, robust, and correct.

Caches can be assumed to be robust and correct, even if they go down
sometimes.  My point was that your `should replace' requirement would
require (correct) caches to mark all unexpired entries as expired if
they come up again after having been down.  This is 1) wasteful and 2)
requires all current cache implementations to be upgraded.

>This then seems to imply a general unpleasant side effect of using
>Location URI != request URI.

No.  Under my scheme, Location URI != request URI does not introduce
robustness problems, for non-expired and expired entries alike.

>  If any frequently changing responses are
>ever sent on a request URI where that URI is also used on some other
>response as a Location header URI != its request URI, the response
>must be uncacheable.

Not just those responses, *any* frequently changing response must be
marked with Pragma: no-cache or Expires: <yesterday>, even if no
alternative URI's are given in Location or URI response headers.

>  Otherwise a non-robust cache that fails to
>notice the Location header going by may get stuck with an out of date
>version of the response.

You are still thinking in terms of a mechanism that makes caches
replace previously cached, but unexpired, copies.  The caching
scenario in my previous message assumed that no such mechanism was
present.

I guess we need a term for the practice of keeping an expired response
in cache memory to facilitate future conditional GET gets.  What about
`conditionally cached'?

Hmm.  I may be on to something.  The spec could use language like
`Pragma: no-cache instructs the cache not to unconditionally cache the
response.  The response may however be cached conditionally.'

>--Shel

Koen.
Received on Thursday, 31 August 1995 15:24:43 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:27 EDT