Re: [squid-users] Squid->DG->Squid

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 [email protected]
>>> 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_at_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