Amos Jeffries wrote
> ==> ORIGINAL_DST is should *only* ever be used on MISS or
> REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is
> the expected behaviour.
>
> For the same reason that a report of the log traffic using "grep -v HIT"
> will show zero cache ratio.
I have
On 09/11/2016 10:23 AM, Amos Jeffries wrote:
> The only visible problem is why that 2% exists.
>
> ==> ORIGINAL_DST is should *only* ever be used on MISS or
> REFRESH/revalidate traffic. Never on a HIT. Thus zero (0%) hit-ratio is
> the expected behaviour.
It is possible that a terminology
On 12/09/2016 3:04 a.m., Omid Kosari wrote:
>
> I refer to following messages .i have same problem
>
The "problem" is misunderstanding of the log entry meaning.
>
> FredT wrote
>> Hi Amos,
>>
>> We have done additional tests in production with ISPs and the ORIGINAL_DST
>> in tproxy cannot be
Antony Stone wrote
> On Thursday 08 September 2016 at 12:27:42, Omid Kosari wrote:
>
>> Hi Fred,
>>
>> Same problem here . Do you found any solution or workaround ?
>
> Please clarify which message you are reply / referring to.
>
> Thanks,
>
>
> Antony.
>
> --
> Archaeologists have found a
On Thursday 08 September 2016 at 12:27:42, Omid Kosari wrote:
> Hi Fred,
>
> Same problem here . Do you found any solution or workaround ?
Please clarify which message you are reply / referring to.
Thanks,
Antony.
--
Archaeologists have found a previously-unknown dinosaur which seems to
Hi Fred,
Same problem here . Do you found any solution or workaround ?
Regards
--
View this message in context:
http://squid-web-proxy-cache.1019090.n4.nabble.com/TProxy-and-client-dst-passthru-tp4670189p4679422.html
Sent from the Squid - Users mailing list archive at Nabble.com.
Hi Amos,
We did tons of tests with the latest Squid versions and this is not the
behaviour with the host_verify_strict off and client_dst_passthru off.
With those 2 options OFF, we see a lot of ORIGINAL_DST that we should not
see if we follow your explainations, so it seems there is a bug
On 4/07/2015 8:02 p.m., Stakres wrote:
Hi Amos,
We did tons of tests with the latest Squid versions and this is not the
behaviour with the host_verify_strict off and client_dst_passthru off.
With those 2 options OFF, we see a lot of ORIGINAL_DST that we should not
see if we follow your
Hi Amos,
Can we expect a workaround to allow the object to the cache if the dns
record is corrected by Squid instead that having an ORIGINAL_DST ?
If Squid corrects the request, it mean the URL will be good, so we should be
able to cache the object
Fred
--
View this message in context:
On 4/07/2015 1:21 a.m., Stakres wrote:
Amos,
You told the Squid will check the original dns from the headers, then it'll
do its own dns resolution to verify they both match.
So, if no match, Squid does the request to internet based on the dns it
found.
If I'm right, that the current way,
Amos,
You told the Squid will check the original dns from the headers, then it'll
do its own dns resolution to verify they both match.
So, if no match, Squid does the request to internet based on the dns it
found.
If I'm right, that the current way, correct ?
What we could do is the same way but
On 4/07/2015 12:05 a.m., Stakres wrote:
Hi Amos,
Can we expect a workaround to allow the object to the cache if the dns
record is corrected by Squid instead that having an ORIGINAL_DST ?
If Squid corrects the request, it mean the URL will be good, so we should be
able to cache the object
Hi,
I'm back to this post because it still does not work.
You explain OFF - Squid selects a (possibly new, or not) IP to be used as
the
server (logs DIRECT)., sorry to say this is not the reality in the Squid.
We have set the pass-thru directive to OFF and here is the result:
TCP_MISS/206 72540
Hi Amos,
216.58.220.36 != www.google.com ???
Have a look: http://www.ip-adress.com/whois/216.58.220.36, this is google.
Depending the DNS server used, the IP can change, we know that especialy due
to BGP.
In the case the client is an ISP providing internet to smaller ISPs with
different DNS
On 2/07/2015 6:32 p.m., Stakres wrote:
Hi,
I'm back to this post because it still does not work.
You explain OFF - Squid selects a (possibly new, or not) IP to be used as
the
server (logs DIRECT)., sorry to say this is not the reality in the Squid.
We have set the pass-thru directive to
Hi Yury,
In your installation, with your devices... At home, I do the same like you,
but I'm not an ISP.
Here the issue is that end users could use different dns the ISPs cannot
control.
Home/Entreprise, the admin can control the used DNS servers with devices. In
an ISP environment, we cannot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fred,
I'm talkin not about localhost installation.
My squid serves business-center. With hundreds of users.
In this environment, we use also transparent DNS interception onto DNS
cache. DNS cache itself uses clean sources for resolving, using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Fred,
I'm talkin not about localhost installation.
My squid serves business-center. With hundreds of users.
In this environment, we use also transparent DNS interception onto DNS
cache. DNS cache itself uses clean sources for resolving, using
Hi Amos,
We have done additional tests in production with ISPs and the ORIGINAL_DST
in tproxy cannot be cached.
In normal mode (not tproxy), ORIGINAL_DST can be cached, no problem.
But once in tproxy (http_port 3128 tproxy), no way, it's impossible to get
TCP_HIT.
We have played with the
On 4/03/2015 8:19 p.m., Stakres wrote:
Hi Eliezer,
Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
client_dst_passthru (off) will stop the DNS entry as explained in the
wiki, the option directly acts on the flag ORIGINAL_DST.
You literally have that backwards.
The cause
Hi All,
Does someone know why the *client_dst_passthru* does not work in TProxy
mode ?
From the Squid wiki, we can read that:
/Regardless of this option setting, when dealing with intercepted
traffic Squid will verify the Host: header and any traffic which
fails Host verification will be treated
Hey Fred,
It is unclear what doesn't work for you.
What would you expect to work and how it works or doesn't work from a
user perspective rather then an admin?
Is there any trouble from the user side about this issue?
Eliezer
On 04/03/2015 00:14, Stakres wrote:
Hi All,
Does someone know
Hi Eliezer,
Well, we have done many tests with Squid (3.1 to 3.5.x), disabling
client_dst_passthru (off) will stop the DNS entry as explained in the
wiki, the option directly acts on the flag ORIGINAL_DST.
As you know, ORIGINAL_DST switches the optimization off (ex: StoreID) then
it's not
23 matches
Mail list logo
