>Can you test if the details at bug 4253:
>
>http://bugs.squid-cache.org/show_bug.cgi?id=4253#c13
>
>Helps you to resolve the issue?
>
>Eliezer
The above bug is not related to the issue.
The issue is actually on origin servers side. Details can be found
here:
http://bugs.squid-cache.org/show_bug
On 2016-10-29 20:40, paul.greene...@verizon.net wrote:
I've inherited a squid proxy at work; I'm new to squid, so this is
still on the learning curve. Unfortunately no one else in the office
is very good with squid either, so I'm attempting to be the resident
guru.
Our network is all in private
On 29/10/2016 8:18 a.m., Garri Djavadyan wrote:
> On 2016-10-28 18:39, Yuri Voinov wrote:
>> It seems bug.
>
>
> On 2016-10-28 19:53, Alex Rousskov wrote:
>>> Is it a bug, documentation error or I simply missed something?
>>
>> It is a bug IMO. The documented intent sounds worth supporting to me.
On 30/10/2016 2:41 p.m., paul.greene.va wrote:
> It is supposed to be some headers in the http protocol; a description from
> the
> vendor:
>
> "Ensure that any proxy, firewall or content filtering applications or devices
> are not stripping header information from FTP or HTTP traffic, especial
It is supposed to be some headers in the http protocol; a description from the vendor:"Ensure that any proxy, firewall or content filtering applications or devices are not stripping header information from FTP or HTTP traffic, especially file size header information." In the SEPM error log, it is s
On 30/10/2016 12:38 p.m., paul.greene.va wrote:
> This fixed the WSUS server, it wasn't the cache_peer parameter after all.
>
> acl inside dstdomain .mydomain.com
> always_direct allow inside
> never_direct allow all
> The SEPM might have an additional known issue (known by Symantec that is)
>
>
This fixed the WSUS server, it wasn't the cache_peer parameter after all.acl inside dstdomain .mydomain.comalways_direct allow inside never_direct allow all The SEPM might have an additional known issue (known by Symantec that is)If a proxy or a firewall is stripping, compressing, or encrypting con
On 30/10/2016 4:40 a.m., paul.greene.va wrote:
>
> Our firewall guy says what he's seeing in his logs is that traffic destined
> for
> port 443, after it goes through the proxy, is trying to go straight to the
> vendor over the internet, rather than go through the upstream McAfee gateway
> as
I've inherited a squid proxy at work; I'm new to squid, so this is still on the learning curve. Unfortunately no one else in the office is very good with squid either, so I'm attempting to be the resident guru.Our network is all in private IP address space. A MS WSUS server and a Symantec Endpoin
