Re: [squid-users] Re: Sibling cache peer for a HTTPS reverse proxy

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Mon, 28 Jul 2014 17:54:46 +1200

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
Received on Mon Jul 28 2014 - 05:54:57 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 28 2014 - 12:00:05 MDT