- From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
- Date: Thu, 17 Oct 1996 20:01:11 +0100 (BST)
- To: Daniel DuBois <dan@spyglass.com>
- Cc: luotonen@netscape.com, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Daniel DuBois wrote: > > > Warnings are always cachable, because they never weaken the transparency > > of a response. This means that warnings can be passed to HTTP/1.0 caches > > without danger; such caches will simply pass the warning along as an > > entity-header in the response. > > ... > > > >This is not right. HTTP/1.0 cache will cache this header, and the > >Warning will remain in the cache file even if the entity is up-to-date > >checked later. So clients could e.g. see a warning saying that the > >response may be stale even if the proxy just did an up-to-date check > >and it was ok. > > What part is not right? "never weaken the transparency" is right. A > warning that the thing is stale even if it's not, doesnt weaken > transparency. "without danger" might not be right if you use an extremely > liberal definition of danger. Perhaps we have different ideas of what "transparency" means, but it seems to me that receiving an entity with an erroneous header is not transparent. It could certainly lead to undesirable behaviour on the part of downstream 1.1 caches, such as periodically trying to refetch the "stale" entity (and, of course, getting another stale one). Cheers, Ben. -- Ben Laurie Phone: +44 (181) 994 6435 Freelance Consultant and Fax: +44 (181) 994 6472 Technical Director Email: ben@algroup.co.uk A.L. Digital Ltd, URL: http://www.algroup.co.uk London, England. Apache Group member (http://www.apache.org)
Received on Thursday, 17 October 1996 13:02:56 UTC