[squid-users] Cannot get ACL to work

Ugh, I am trying to get Squid to deny access to a particular AD group, but when I enable the rule, then it denys everyone. This is what I have in squid.conf # NTLM auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp auth_param ntlm children 15 auth_param

Re: [squid-users] Introducing delay to HTTP 407 responses

I just want to throw my support behind seeking a solution to this problem. Luke’s clearly considered it in way more detail than anyone so far, myself included. The affects the squids under my purview every day. Best, Dan > On 14 Sep. 2016, at 10:18 am, squid-us...@filter.luko.org wrote: > >

[squid-users] c-icap load balancing

Hi Unlickily,I meet a problem.I want to implement the c-icap cluster.the traffic averagely distribute to each c-icap.but I just found the adaptation_srvices_set and adaptation_services_chain. adaptation_service_set is useful when hot standby or backup adaptation servers are available.The

[squid-users] Introducing delay to HTTP 407 responses

Hi Squid users, Seeking advice on how to slow down 407 responses to broken Apple & MS clients, which seem to retry at very short intervals and quickly fill the access.log with garbage. The problem is very similar to this: http://www.squid-cache.org/mail-archive/squid-users/201404/0326.html

Re: [squid-users] Web Whatsapp, Dropbox... problem

Not really, As I understand it it is a websocket, that when proxied starts its handshake with a connect request so it can be "understood" by proxies such as squid. Chico Venancio ___ squid-users mailing list squid-users@lists.squid-cache.org

Re: [squid-users] Web Whatsapp, Dropbox... problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ah, my mistake. This is simple tunnel. 14.09.2016 3:03, Chico Venancio пишет: > You mean the connect requests to the websockets on w[0-9].web.whatsapp.com > ? > > 1473800440.053 16932 192.168.10.128 TCP_TUNNEL/200

Re: [squid-users] Web Whatsapp, Dropbox... problem

You mean the connect requests to the websockets on w[0-9].web.whatsapp.com ? 1473800440.053 16932 192.168.10.128 TCP_TUNNEL/200 3639 CONNECT w7.web.whatsapp.com:443 - HIER_DIRECT/169.55.69.156 - Chico Venancio 2016-09-13 17:40 GMT-03:00 Yuri Voinov : > > -BEGIN PGP

Re: [squid-users] Web Whatsapp, Dropbox... problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Wait. Does anybody see WebSockets connections to web.whatsapp.com? 14.09.2016 2:38, Chico Venancio пишет: > > We need more of access log. > There is at least connect attempts at w1.web.whatsapp.com not shown. > >

Re: [squid-users] Rock store status

On 09/13/2016 05:01 AM, FredB wrote: > One thing, squid restart is very slow because of time required to rebuild the > cache > > 2016/09/13 00:25:34| Took 1498.42 seconds (3972.24 objects/sec). -> Rock > 2016/09/13 00:00:51| Took 5.71 seconds (533481.90 objects/sec). -> Diskd This is a

Re: [squid-users] Lost of all squid cache

Hey Eduardo, The first thing I would do is to first disable the disk cache in order to try to recover\rebuild the disk cache manually using another squid instance. It's not always possible but if this cache is important enough then a loss of couple tiny bits for recovery time plus some network

Re: [squid-users] Web Whatsapp, Dropbox... problem

Hi. Sorry but... dont work... In the chrome i get this Creating Application Cache with manifest https://web.whatsapp.com/404.appcache web.whatsapp.com/:1 Application Cache Checking event web.whatsapp.com/:1 Application Cache Error event: Manifest fetch failed (404)

Re: [squid-users] Lost of all squid cache

Jorgeley wrote > what about cache_swap_low and cache_swap_high??? > > 2016-09-13 8:23 GMT-03:00 Eduardo Carneiro > eduardoocarneiro@ > : > >> Amos Jeffries wrote >> > On 13/09/2016 5:12 a.m., Yuri Voinov wrote: >> >> >> >> Hm. >> >> >> >> As a recovery you can try to rename/remove swap.state

Re: [squid-users] Lost of all squid cache

what about cache_swap_low and cache_swap_high??? 2016-09-13 8:23 GMT-03:00 Eduardo Carneiro : > Amos Jeffries wrote > > On 13/09/2016 5:12 a.m., Yuri Voinov wrote: > >> > >> Hm. > >> > >> As a recovery you can try to rename/remove swap.state from cache_dir's > >> and

Re: [squid-users] Lost of all squid cache

Amos Jeffries wrote > On 13/09/2016 5:12 a.m., Yuri Voinov wrote: >> >> Hm. >> >> As a recovery you can try to rename/remove swap.state from cache_dir's >> and start squid again. AFAIK in this case it re-indexing all exists disk >> cache contents and build new one swap.state file. Also, does all

Re: [squid-users] Rock store status

One thing, squid restart is very slow because of time required to rebuild the cache 2016/09/13 00:25:34| Took 1498.42 seconds (3972.24 objects/sec). -> Rock 2016/09/13 00:00:51| Took 5.71 seconds (533481.90 objects/sec). -> Diskd ___ squid-users

Re: [squid-users] TProxy and client_dst_passthru

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

Re: [squid-users] caching store increase then decrease during caching windows updates and all request are TCP_MISS ??!!!

Just as a side note to the server insisting on the full object: Since we believe and estimate that SHA digests are considered collision safe on the 100+ MB files sizes for the next couple years it is safe to assume(from my point of view on things) that if the whole file was digested with a SHA1