[squid-users] Squid going through another forward proxy

[Hector Chan]

Ah, I think I have a typo in my question.  Originally, I mentioned the
following:

> the logic of figuring out where to go to lies in (C).

What I actually meant is "the logic that figuring out where to go lies in
(B)" (not C).

On Thu, Nov 13, 2014 at 5:14 PM, Hector Chan <hectorchan at gmail.com> wrote:

> Hi Amos,
>
> Thanks for your reply.  Let's say I have the following cache_peer lines in
> (B), and the address for (C) is "forward-proxy.example.com:3128".
>
> cache_peer    origin-x.example.com    parent 443 0 no-query originserver
> ssl
> cache_peer    origin-y.example.com    parent 443 0 no-query originserver
> ssl
> cache_peer    origin-z.example.com    parent 443 0 no-query originserver
> ssl
>
> What would be the syntax to configure (B) to use "
> forward-proxy.example.com:3128" (C) as the forward proxy to the origin
> servers (D) ?
>
> Thanks again,
> Hector
>
>
>
> On Thu, Nov 13, 2014 at 4:13 PM, Amos Jeffries <squid3 at treenet.co.nz>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 14/11/2014 10:36 a.m., Hector Chan wrote:
>> > Basically, what I am looking for is whether it's possible to set up
>> > the following:
>> >
>> > Client (A) --> Squid as Reverse Proxy (B) --> Squid as Forward
>> > Proxy (C) --> Origin Servers Depending on Client Request URI (D)
>> >
>> > Depending on the client request from (A), (B) could route the
>> > request to different origin servers (multiple cache_peer lines).
>> > The request has to go through (C) to reach (D), as (C) is the only
>> > way out of the network to the internet.  Moreover, the logic of
>> > figuring out where to go to lies in (C).
>> >
>> > I know it's kind of a weird setup, but, unfortunately, we do not
>> > have access or control of (A) and (C).
>>
>> Nothing weird about that at all. It is a perfectly normal CDN proxy
>> chain. The only potentially tricky bit will be getting the domain
>> owner to add your reverse-proxy IP address to the domain.
>>
>> Forward/reverse are *input* modes, indicating the HTTP syntax expected
>> and resulting behaviour. Any type of proxy can be configured with a
>> cache_peer for *output*.
>>
>> Only the interception proxy have problems with cache_peer sometimes,
>> because their very existence is a violation of the protocol.
>>
>> Amos
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.22 (MingW32)
>>
>> iQEcBAEBAgAGBQJUZUkXAAoJELJo5wb/XPRj3F8H/2OIGI+RGJuJCWmH13cCmbdZ
>> jA4GZDYU8QgGPx6eUJ5kCVQPi31nnkNKtfv5WFfhetj7syYj40ow+C0DDaUCsPT/
>> udVBLMqA/qaoEYkT6q6mTu7D5xio/Gsd+SjBmPG7w6mJx6YiAceoP7/61/7EKZNA
>> vMTFfCuubh8a0IDSOajMUlf/ZRlRXkYNEnZMeGTliCKz2vnA/gjasu5fJcDPUunl
>> 6JpYa4DRfYZ2S3vElyCnkInN53XkQDcTLKBR4jKIXvsjfVuc4mYxDf2TQj8hhIy0
>> 5TGzAtMq4D53LuyH3mGN2mK0OO6itGO5k+ALHIiDgGoP6AoZU6oIqjuaLPV117k=
>> =NIK1
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20141113/7f887fad/attachment.html>