Re: 13.1.2 Warnings
Ari Luotonen (luotonen@netscape.com)
Thu, 17 Oct 1996 13:17:15 -0700 (PDT)
> > 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