Re: Squid, Reload and cache hierarchies

From: Duane Wessels <wessels>
Date: Wed, 17 Jul 96 12:46:15 -0700

bortzmeyer@pasteur.fr writes:

>
>I have some problems understanding the behaviour of Squid in a cache
>hierarchy when an user chooses "Reload" on his browser.
>
>Symptom: Lynx ("This page looks great with Lynx, download it now!") and
>Netscape have two different results.
>
>Configuration: a Squid 1.0.0 cache running on FreeBSD, child of a Squid
>1.0.0 cache running on Alpha/OSF1. Users are clients of the first one,
>they use Netscape or Lynx on Unix boxes.
>
>Explanation: Lynx does a "hard" reload, sending "Pragma: no-cache" but no
>"If-Modified-Since" while Netscape uses both headers.
>
>Therefore, when a Lynx reload hits Squid, Squid sends an ICP request to
>its parent which does *not* include the "Pragma: no-cache" :-( (Weakness
>in ICP?) If the parent has the page in its cache, it sends it back and no
>real reload was done.

Hm, it must be that the object is returned in a HIT_OBJ reply?
That can (and will) be fixed.

>On the other hand, when Netscape reloads, Squid bypasses the hierarchy
>because of the "If-Modified-Since" :-( (See Release-Notes-1.0.txt.) So,
>the desire of Netscape to save bandwidth leads to more resource
>comsuption.

This can probably be changed too, now that Squid handles IMS a little
differently.

It used to be that Squid treated all IMS requests as MISSes. It would
then forward the request directly to the origin server. One reason
for that is because we expect most (95%?) of IMS requests will
end up being "304 Not Modified."

But now Squid treats IMS requests as a MISS if the object is
not in the cache, or if it has expired. I think it will be okay
to use the hierarchy for an IMS request if all the neighbors
support the private keys for ICP queries.

I can send you a patch to try....

Duane W.
Received on Wed Jul 17 1996 - 12:46:15 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:36 MST