<div dir="ltr"><div><div>Hi Amos,<br><br>For the following cache_peer:<span class="im"><br><br>> cache_peer <a href="http://forward-proxy.example.com" target="_blank">forward-proxy.example.com</a> parent 3128 0 name=C<br><br></span></div>Would squid do the proper HTTP CONNECT before forwarding the request there ?<br><br></div>Thanks,<br>Hector</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 10:35 PM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span><span class="">On 14/11/2014 6:22 p.m., Hector Chan wrote:<br>
> Hi Amos,<br>
><br>
</span><span class="">>> those lines you specify above go in (C). *if* they are needed at<br>
>> all.<br>
><br>
> But I don't have control over (C).  It's off limits.<br>
<br>
</span>Then you have to trust that the admin in charge of it set it up right.<br>
<span class=""><br>
><br>
>> In (B) goes:<br>
>><br>
>> cache_peer <a href="http://forward-proxy.example.com" target="_blank">forward-proxy.example.com</a> parent 3128 0 name=C<br>
>><br>
>> acl sendToC dstdomain <a href="http://origin-x.example.com" target="_blank">origin-x.example.com</a> <a href="http://origin-y.example.com" target="_blank">origin-y.example.com</a><br>
> <a href="http://origin-z.example.com" target="_blank">origin-z.example.com</a><br>
>> cache_peer_access C sendToC<br>
><br>
> The requests reaching (B) (<a href="http://reverse-proxy.example.com" target="_blank">reverse-proxy.example.com</a>) are in the<br>
> form: <a href="http://reverse-proxy.example.com/goto-origin-x" target="_blank">http://reverse-proxy.example.com/goto-origin-x</a><br>
> <a href="http://reverse-proxy.example.com/goto-origin-y" target="_blank">http://reverse-proxy.example.com/goto-origin-y</a><br>
> <a href="http://reverse-proxy.example.com/goto-origin-z" target="_blank">http://reverse-proxy.example.com/goto-origin-z</a><br>
><br>
> and I have a couple of cache_peer_access acls (urlpath regex) to<br>
> send them to origin-x, origin-y, and origin-z.  How would the above<br>
> dstdomain acl work with these rules?<br>
<br>
</span>You have now stopped using HTTP and started using some strange<br>
URL-embeded protocol.<br>
<br>
An HTTP proxy cannot help you there. You require a proxy that<br>
understands and acts on the URL-embeded protocol messages.<br>
<br>
It is possible to extend Squid with URL-rewrite helpers that can<br>
translate it into different HTTP URL for passing to (C). BUT, there is<br>
no guarantee of what origin (C) will use to fetch that resource. You<br>
have to *trust* that (C) uses the origin best suited to any request<br>
that it is given, according to the criteria its own admin has set for<br>
"best".<br>
<span class=""><br>
Amos<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
</span>iQEcBAEBAgAGBQJUZaKVAAoJELJo5wb/XPRjdpQH/iBh1HQcAZQr0gqK7FS8nZ9x<br>
v0fzAOx/L0HCG5MTT7drwvvEVltxMRYoVniM8VJSqUw3cFAlI+2VEScIr3oOFjcr<br>
qAdjxyjer7sxVgmQM80Oa+n40RK7mvZejvhEV9/0Gc0XTmAjL3PrBptKpumslhVh<br>
rq40LUX50rg5xaAfA02WCy4mYS99uH7qBABWIXeeESVdvGLVRTaTlthqaKW8JTFh<br>
pjmS9OKVnk5CeEi6cyJ8VV7edBOgv2rpgUH8Wjap66mmIjVHq8alNU53obRAMk7p<br>
Pd/bPfPFERnoBymbYmYfFBd3Mfddgc49Wpz9gggAWgXE8bq6CbXQHpj5GvUayaE=<br>
=mS+q<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>