Search squid archive

Re: Re: Sibling cache peer for a HTTPS reverse proxy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 27/07/2014 1:34 a.m., Makson wrote:
> Amos Jeffries wrote
>> Showing that server B is in fact qeuerying server A for the objects. But
>> it would seem that server A did not have them cached.
>>
>> It may be that these responses use Vary: header. ICP does not handle
>> that type of response properly. You may get better behaviour using HTCP
>> instead of ICP between the siblings.
>>
>>
>> I also note that you have 40GB of RAM allocated to each of these Squid
>> instances. Do you actually have over 100GB of RAM on those machines
>> (*excluding* swap space)?
>>
>> Amos
> 
> Hi Amos,
> 
> Thanks for your reply, i am now using HTCP, still don't get it work :-( ,

Ah. Been scratching my head over this for a while.

The log records you mentioned shoed two things hich might be interfering.

1) https:// on the URLs. Squid is not suposed to be sending these over
un-encrypted peer connections. I dont recall any explicit prevention of
that, but there might be.

2) explicit hostname "serverb.domain:9443". I find it highly unlikely
that you will be finding server A being requested for URLs at that hostname.

All publicly visible URLs from "app.domain" going through these proxies
should be using the public[1] domain name for app.domain's service, not
the proxies unique hostname:port's. That includes your testing requests.

[1] public in the context that clients are told it, not necessarily
Internet-public.

Amos





[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux