- From: Ari Luotonen <luotonen@netscape.com>
- Date: Thu, 17 Oct 1996 13:17:15 -0700 (PDT)
- To: ben@algroup.co.uk
- Cc: dan@spyglass.com, luotonen@netscape.com, masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> > What part is not right? "never weaken the transparency" is right. A > > 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). Agree with Ben. I think it's undesirable if I get a Warning header when there it's not suppose to be there. Say I hav document X, last-modified at Y. The document is cached in HTTP/1.1 cache A. An HTTP/1.0 cache B requests for this document X from the cache A. Cache A returns it directly from its cache without an up-to-date check, and attaches the Warning header of that fact. Cache B caches the Warning header. Later cache B receives another request for the document X and determines it's time to do an up-to-date check. Cache A has also reached the time to do an up-to-date check. So an up-to-date check is made, and the remote server reponds that X has not been modified since date Y, and is hence still up-to-date. Now, cache A responds to B saying B's copy is up-to-date. Unfortunately, the Warning header will (erroneously) remain in the cache of B and will be passed to the user, forever giving the perception that the returned copy may be stale, even though in this case it was guaranteed to be up-to-date. Cheers, -- Ari Luotonen * * * Opinions my own, not Netscape's * * * Netscape Communications Corp. ari@netscape.com 501 East Middlefield Road http://home.netscape.com/people/ari/ Mountain View, CA 94043, USA Netscape Proxy Server Development
Received on Thursday, 17 October 1996 13:24:13 UTC