- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Thu, 17 Oct 96 16:01:17 MDT
- To: ben@algroup.co.uk
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
In response to my option #1:
> (1) Live with it. This can only happen when an HTTP/1.0
> cache is a client of an HTTP/1.1 cache, and presumably
> in somewhat unusual cases, so maybe it's a temporary
> problem.
You replied:
Something you'd have to live with for a long time, I suspect. Not
an acceptable option, IMHO.
I.e., you expect this kind of situation to persist for a while:
[Server]---[HTTP/1.1 cache]---[HTTP/1.0 cache]---[HTTP/1.1 client]
But then, regarding my suggestion to not send Warning to an HTTP/1.0
client,
This would seem the appropriate solution. Not giving a Warning
where the client doesn't understand it would seem a small price
to pay.
But in the situation that is of interest, this is not a case
where the *end-client* doesn't understand the Warning (or else
it wouldn't be an issue). It's a case where a proxy *between*
two systems that understand Warning doesn't understand it.
So we're back to risking "undetected stale pages" in a situation
where we could, in fact, detect them.
> One possibility: HTTP/1.1 clients (the only ones that could
> care about a Warning header anyway) should turn a Reload on
> a page with a "Warning: stale" into a "Pragma: no-cache". That
> would cause a few extra cache misses, but would break the
> infinite loop that you are worried about.
I prefer the idea of leaving the Warning out. I see no gain from
forcibly removing the stale entry from downstream caches.
The main point of my previous message was not to enumerate the
complete set of possible solutions, but to prod the people who
are complaining about the current situation to suggest some
alternative that isn't worse than the problem it purports to
solve.
Sending "Pragma: no-cache" might not be the best solution. I
strongly encourage people to improve upon it. Be creative!
-Jeff
Received on Thursday, 17 October 1996 16:15:05 UTC