W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 1996

Re: 13.1.2 Warnings

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Thu, 17 Oct 96 13:47:37 MDT
Message-Id: <9610172047.AA14943@acetes.pa.dec.com>
To: Ari Luotonen <luotonen@netscape.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1796
You've made a convincing case that the existing design for Warning
can yield bogus Warnings when HTTP/1.0 and HTTP/1.1 caches are
combined.  (I believe we wrote the HTTP/1.1 caching rules so that
an HTTP/1.1 cache in the position of your cache "B" would remove
the Warning after doing a successful validation from cache "A",
but of course it's too late to apply that to the HTTP/1.0 caches
out there.)

So please suggest a solution!

I can see three options:
	(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.
	(2) Remove Warning: stale from the protocol, on the grounds
	that it's better to silently give many users stale pages,
	instead of bogusly warning a few users about non-stale pages.
	[I don't consider this option to be a wise choice.]
	(3) Fix the design so that it works with HTTP/1.0 caches.
	Perhaps, for example, this means that one can't send a
	"Warning" to an HTTP/1.0 client (but this would also
	cause a lack of Warning in cases where it would be
	apppropriate).

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.

-Jeff
Received on Thursday, 17 October 1996 13:58:47 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:00 UTC