So what should I do about this? Is it a configuration issue, or shall
I report it as a bug?
On Fri, Sep 21, 2012 at 1:21 PM, Nathan Hoad wrote:
> On Thu, Sep 20, 2012 at 9:19 PM, Amos Jeffries wrote:
>>
>>
>> The suspicious thing about this is that client aborts after only 83
>> milliseconds. B
On Thu, Sep 20, 2012 at 9:19 PM, Amos Jeffries wrote:
>
>
> The suspicious thing about this is that client aborts after only 83
> milliseconds. Barely enough time to get DNS data and start the TCP handshake
> to upstream on a MISS. You can expect RTT to be between 50 and 150
> milliseconds to most
On 20/09/2012 6:44 p.m., Nathan Hoad wrote:
On Thu, Sep 20, 2012 at 2:30 PM, Amos Jeffries wrote:
From your use of client_dst_passthru I assume you have this Squid configured
as a transparent interception proxy?
Yes, but it is also configured as a direct proxy.
This is apache format for web
On Thu, Sep 20, 2012 at 2:30 PM, Amos Jeffries wrote:
>
> From your use of client_dst_passthru I assume you have this Squid configured
> as a transparent interception proxy?
Yes, but it is also configured as a direct proxy.
>
> This is apache format for web end-servers. Do you have anything in S
On 20/09/2012 3:53 p.m., Nathan Hoad wrote:
Hello all,
I'm running Squid 3.2.1, with a cache_peer configured to point at
another local Squid instance as a parent proxy. The parent proxy is
not getting reliably hit, for the *exact* same url.
acl objectcache url_regex -i "/path/to/regexes"
cache
Hello all,
I'm running Squid 3.2.1, with a cache_peer configured to point at
another local Squid instance as a parent proxy. The parent proxy is
not getting reliably hit, for the *exact* same url.
acl objectcache url_regex -i "/path/to/regexes"
cache_peer localhost parent 60084 0 proxy-only
name