Re: 13.1.2 Warnings

Jeffrey Mogul wrote:
> 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!

OK, here's my creative solution ... a 1.1 proxy receiving a Warning should
make the entity look out-of-date to any 1.0 clients. The Warning can then be
safely cached in 1.0 caches, because it will be cleared by a fresh copy of the
same entity without the Warning which looks more up-to-date than the cached

Whether 1.0 caches will store an "older" copy is an interesting question,
though. If they don't, then this solution has the same net effect as leaving
the Warning out, if they do, then the Warning can be propogated to downstream
caches without poisoning them.



Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email:
A.L. Digital Ltd,           URL:
London, England.            Apache Group member (

Received on Friday, 18 October 1996 04:03:56 UTC