Hi,
still using my 4 siblings in proxy-only.
Works fine for a while... until the digests are exchanged.
As expected, my logs are full of forwarding loops detected.
2008/07/11 10:48:32| WARNING: Forwarding loop detected for:
Client: 192.168.17.11 http_port: 192.168.17.11:8000
GET http://192.
Hi all,
We use trend micro's internet web security suite for virus and content
filtering.
Squid is setup to forward any request to the IWSS then IWSS makes squid
do the final
Request, so squid - IWSS - squid. We require to be like this so
accounting and error
Pages are handled correctly.
This
John Doe wrote:
Hi,
still using my 4 siblings in proxy-only.
Works fine for a while... until the digests are exchanged.
As expected, my logs are full of forwarding loops detected.
2008/07/11 10:48:32| WARNING: Forwarding loop detected for:
Client: 192.168.17.11 http_port: 192.168.17.11:8000
On fre, 2008-07-11 at 03:57 -0700, John Doe wrote:
> Works fine for a while... until the digests are exchanged.
> As expected, my logs are full of forwarding loops detected.
Hmm... you SHOULD NOT see loops unless you are using the allow-miss
cache_peer option, as by default Squid adds a "Cache-Con
> > still using my 4 siblings in proxy-only.
> > Works fine for a while... until the digests are exchanged.
> > As expected, my logs are full of forwarding loops detected.
> >
> > The problem is, since the siblings are in 'proxy-only', they do not cache
> > the
> looped objects and constantly as
> > Works fine for a while... until the digests are exchanged.
> > As expected, my logs are full of forwarding loops detected.
>
> Hmm... you SHOULD NOT see loops unless you are using the allow-miss
> cache_peer option, as by default Squid adds a "Cache-Control:
> only-if-cached" control to reques
On fre, 2008-07-11 at 07:49 -0700, John Doe wrote:
> I don't have use allow-miss.
> But I do have:
> header_access Cache-Control deny all
> header_replace Cache-Control max-age=864000
> I will try without it...
That explains the loops in sibling setup.
But it does not explain why your cache_peer
Henrik Nordstrom wrote:
On fre, 2008-07-11 at 07:49 -0700, John Doe wrote:
I don't have use allow-miss.
But I do have:
header_access Cache-Control deny all
header_replace Cache-Control max-age=864000
I will try without it...
That explains the loops in sibling setup.
But it does not e
Hi,
sorry, I was a bit busy.
So I did put back the tcp_outgoing_address.
Will I have to use it forever or just for testing?
Does it have to be an IP different than the regular IP?
Again, post a bit long...
squid1: 192.168.17.11 / tcp_ougoing 192.168.17.15
squid2: 192.168.17.12 / tcp_ougoing 192.
On tor, 2008-07-17 at 08:17 -0700, John Doe wrote:
> So I did put back the tcp_outgoing_address.
> Will I have to use it forever or just for testing?
You should have it for as long as you are running multiple instances on
the same server..
> Does it have to be an IP different than the regular IP?
> For some reason squid4 thought squid2 had the object, but it didn't (or
> it had expired) so Squid4 recovered by going to apache. As there was no
> UDP traffic it's most likely a digest false hit.
Is there a way to fall back to ICP communication in case of a digest false
hit...?
Like: squidx ha
On fre, 2008-07-18 at 04:18 -0700, John Doe wrote:
> Is there a way to fall back to ICP communication in case of a digest false
> hit...?
> Like: squidx has object. Oops, no he does not. Let's ask the others...
Unfortunately not. But it's a good idea.
Regards
Henrik
signature.asc
Descriptio
On Tue, 14 Jun 2005, Adam Clark wrote:
Squid is setup to forward any request to the IWSS then IWSS makes squid
do the final Request, so squid - IWSS - squid. We require to be like
this so accounting and error Pages are handled correctly.
This all works very nicely but has a side effect of fo
13 matches
Mail list logo
