Going DIRECT rather than through parent.

From: Donovan Baarda <abo@dont-contact.us>
Date: Fri, 24 Oct 1997 10:30:45 +1000 (EST)

On Thu, 23 Oct 1997, Larmour, Jonathan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Since it was DIRECT rather than TIMEOUT_DIRECT that can only mean
> that something was forcing it not to cache, so the URL could either
> be in a cache_stoplist or hierarchy_stoplist, or the browser
> specified "Pragma: no-cache" so that it must be fetched direct. e.g.
> someone hit Shift-reload in their browser, or someone's using the
> Netscape Communicator beta's that have the bug that always means it
> sends "Pragma: no-cache". Or if someone is using IE3, apparently (in
> some versions?) if you tell it to check the cache all the time, then
> instead of just checking the cache, it sends "Pragma: no-cache" with
> it too!
>
> Can you check if its one of these possibilities?
>
Yep, can check. It was netscape 2.02, no Shift-reload, and my config has;

cache_host proxy.name.au parent 8080 3130
cache_host_domain proxy.name.au !myhost.my.domain
single_parent_bypass off
source_ping off
neighbour_timeout 4
local_domain myhost.my.domain
hierarchy_stoplist
cache_stoplist cgi-bin ?
cache_stoplist myhost.my.domain

There is nothing in my config that could cause it to go direct for the
URL's in question. The only thing that may be contributing is the URL I'm
looking at seems to have a very short lifetime, and nearly every time I
hit it it gives TCP_REFRESH_MISS (no, this URL doesn't have a "?" or
"cgi-bin" in it). In fact, here is the entrys from my logs;

access.log
877650081.718 57263 203.12.237.35 TCP_REFRESH_MISS/200 4881 GET
http://www.altavista.yellowpages.com.au/ -
DIRECT/www.altavista.yellowpages.com.au text/html

store.log
877650081.718 SWAPOUT 200 -2 -2 -2 text/html
4815/4815 GET http://www.altavista.yellowpages.com.au/

Note that at the time these were taken, the parent cache was down and this
was reflected in the server information of cachemgr. However, even when
the parent is up, this is what I get for this URL. From my understanding,
squid should have ICP'ed the parent, waited 4 seconds for a responce, and
then gone TIMEOUT_DIRECT (if the parent was down) or FIRST_PARENT_MISS (if
the parent was up).

At the moment, the only way I can make it go through the parent for this
URL is to put "inside_firewall myhost.my.domain" in the config, but this
means I get nothing if the parent is down.

The more I read about other peoples problems, the more I think it looks
like squid "pings" the source even with source_ping off. Either that or it
modifies it's algorithm for URL's fetched with TCP_REFRESH_MISS based on
what happend last time.

ABO
Received on Thu Oct 23 1997 - 17:39:47 MDT

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