On 29/07/11 20:01, Andrew Rogers wrote:
Hi Amos
Thanks for the reply again
"TCP_REFRESH_UNMODIFIED" not which are showing like:-
1311836509.795 162 localhost TCP_REFRESH_UNMODIFIED/304 553 GET
http://i2.cdnds.net/11/30/P/gaming_sidpirates1.jpg -
DIRECT/213.244.185.38 -
1311836509.795 163 mycomp.tg.local TCP_MISS/304 691 GET
http://i2.cdnds.net/11/30/P/gaming_sidpirates1.jpg me@MY.LOCAL
FIRST_UP_PARENT/127.0.0.1
Which iam assumeing it has had a successfull cache hit from Squid2?
Looks that way. The particular example was a revalidation request though. If
they are both logging to the one file first line is squid2, second line
squid1?
Yes Squid 2 is line 1
With you saying Cache MISS is seperate, will using the 2 seperate
Squid instances automatically have a better hit rate by the looks
already from here?
Some requests are best served that way rather than going through a
hierarchy. Such as CONNECT requests which are explicit requests to do that.
nonhierarchichal_direct and hierarchy_stoplist control whether these types
of requests are required to go through the peer (DG) or allowed to go
direct.
Could you explain a little more in detail what CONNECT request's are actually?
A request from some client to open a 2-way TCP connection / tunnel to a
specified host and port. Similar in properties to a telnet connection
once made. So very unsafe to allow.
Should I always trust these kind of connections and let them go direct
if the connection has authentication against it with a possible
statement of:-
always_direct allow CONNECT auth
CONNECT are absolutely not trustworthy. The one exception we have to
make by default is port 443 because HTTPS requests need it to transmit
the SSL data. You are free to extend that list to allow known
application ports, just be careful.
Once its past your criteria for allowing its safe to relay via another
proxy. Just slower than it would have been doing it locally.
I had a couple of instances yesterday when someone was trying to
access an kind of echosign document which loaded up fine but then just
did not go through, can you tell from the log below what has happened
to the site?
1311862760.709 2021 localhost TCP_MISS/200 8591 CONNECT
supplier.echosign.com:443 - DIRECT/72.3.215.121 -
1311862760.710 2094 jzs.tg.local TCP_MISS/000 8630 CONNECT
supplier.echosign.com:443 jzs@TG.LOCAL FIRST_UP_PARENT/127.0.0.1 -
http_reply_access is *way* too late to be doing anything like destination
selection. The request has already left squid via some path and the reply is
coming back.
Should I then just not use http_reply_access, or if I do need it where
in my config about should I locate this?
http_reply_access is usually only needed for things like file mime type
checks on the reply. Location overall in the config does not matter, but
order within any set of lines with the same directive name relative to
each other always does.
hierarchy_stoplist cgi-bin ?
any URL with "?" or "cgi-bin" in it will go DIRECT from this Squid.
Remove "hierarchy_stoplist".
Add these:
nonhierarchical_direct off
Would not having the line of "nonhierarchical_direct off" in my config
yesterday have maybe caused the CONNECT issue I haev listed above or
would this be completly unrelated?
The "TCP_MISS/000"? ~8600 bytes got transferred through both squid
logging there. The "000" should be only cosmetic.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.14
Beta testers wanted for 3.2.0.10
