<div dir="ltr"><div><div>Hi Amos,<br><br>> those lines you specify above go in (C). *if* they are needed at all.<br><br>But I don't have control over (C).  It's off limits.  <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></div>The requests reaching (B) (<a href="http://reverse-proxy.example.com" target="_blank">reverse-proxy.example.com</a>) are in the form: <br>     <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></div>and I have a couple of cache_peer_access acls (urlpath regex) to send them to origin-x, origin-y, and origin-z.  How would the above dstdomain acl work with these rules?<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 13, 2014 at 7:38 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>-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span><span>On 14/11/2014 4:03 p.m., Hector Chan wrote:<br>
> Ah, I think I have a typo in my question.  Originally, I mentioned<br>
> the following:<br>
><br>
>> the logic of figuring out where to go to lies in (C).<br>
><br>
> What I actually meant is "the logic that figuring out where to go<br>
> lies in (B)" (not C).<br>
><br>
<br>
</span>Actually both require that logic. Relative to the traffic each is<br>
receiving.<br>
<span><br>
<br>
<br>
> On Thu, Nov 13, 2014 at 5:14 PM, Hector Chan wrote:<br>
><br>
>> Hi Amos,<br>
>><br>
>> Thanks for your reply.  Let's say I have the following cache_peer<br>
>> lines in (B), and the address for (C) is<br>
>> "<a href="http://forward-proxy.example.com:3128" target="_blank">forward-proxy.example.com:3128</a>".<br>
>><br>
>> cache_peer    <a href="http://origin-x.example.com" target="_blank">origin-x.example.com</a>    parent 443 0 no-query<br>
>> originserver ssl cache_peer    <a href="http://origin-y.example.com" target="_blank">origin-y.example.com</a>    parent 443<br>
>> 0 no-query originserver ssl cache_peer    <a href="http://origin-z.example.com" target="_blank">origin-z.example.com</a><br>
>> parent 443 0 no-query originserver ssl<br>
>><br>
>> What would be the syntax to configure (B) to use "<br>
>> <a href="http://forward-proxy.example.com:3128" target="_blank">forward-proxy.example.com:3128</a>" (C) as the forward proxy to the<br>
>> origin servers (D) ?<br>
<br>
</span>those lines you specify above go in (C). *if* they are needed at all.<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>
<br>
OR, since you say C is the *only* way to access the Internet you can<br>
omit the acl and cache_peer_access lines. Which will cause all traffic<br>
to try and go through C.<br>
<span><br>
Amos<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
<br>
</span>iQEcBAEBAgAGBQJUZXkaAAoJELJo5wb/XPRjNaYH/0rD/r4hepby40bDQnLTzJyr<br>
BP5CY/WP6tqBvavJHpJE41TpRhhx6HilZSWccAnhe5Dk7O+wit2rbp4lxZqXID01<br>
6sxzPb6IjXldgXd6vmjCzkK8QiDFdFjEev2+26LAX6cPuQOEuiyzCiFFHzI6TK7c<br>
lXGqDGbkTmBtIplHVAz/7u4IJlb2TNbT23wkzt6jJHUBYxhhY23g3x1sT4Tc045U<br>
oseTZnazY+Ehrglf/NdNJfBAkcl71Lp65rxDLvo2ayUNffiXeg6bNtd7oGHyZ0S3<br>
MMUxsF2XA7kDxgPCtD5qhVFnxnhTKCMawz3gf6PRxRlSqeCxB+FrWx01frblx2s=<br>
=VsYA<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div></div>