Re: [squid-users] icp_hits not giving http requests

G'day,

I just joined the list recently, was searching through the archives, and
found this.

[...]
> Pranav Desai wrote:
> >
> > but the child does receive icp_hits as seen in the server_list ....
> >
> > On Wed, 6 Jun 2001, Henrik Nordstrom wrote:
> >
> > > It might be that the child times out the ICP query before the reply is
> > > seen. The automatic timeout calculation is not flawless..
> > >
> > > Try setting icp_query_timeout to a explicit value you feel comfortable
> > > with.

I have seen this behaviour too, and it's not because of ICP timeouts.

Where I've seen it is with the parent configured to "icp_hit_stale". The
parent sends a UDP_HIT for a stale url to the child, the child then fetches
from the parent, but the parent returns TCP_REFRESH_MISS with a 504 result
code (server timeout). The child then re-tries fetching via another source.

The bit that gets confusing is the access.log in the child only shows the
fetch via the other source. The parent access.log shows all the UDP_HITs,
but also shows the TCP_REFRESH_MISS stuff.

I have no idea why it does this. It looks like the parent doesn't even
attempt to validate the stale url with an IMS request upstream. Many stale
urls (particularly big ones, like .gif, .deb, .rpm, .tar.gz) can be
revalidated by an IMS request without downloading them all over again. The
only possible reason I can see for this behaviour is to "fix" the problems
that can occur when using icp_hit_stale with miss_access denied siblings.

I'm not happy with this behaviour and would like it fixed, because I have a
parent with a large amount of "stale" content that is being wasted. Any
Squid guru's know how to fix this?

ABO
Received on Thu Jul 05 2001 - 22:39:13 MDT