<div dir="ltr">Attached is the patch,<div><br></div><div>This is the first time I have created a variable or really done anything inside the http request processing flow so feel free to let me know if there is a better way to do something or if I have any edge cases.</div>
<div><br></div><div>This patch provides a $upstream_connecting variable which contains the IP address and port of the upstream being connected. If there is no upstream, it will return "-" my understanding is this may happen if the upstream is DNS resolved (untested). There may be a better way of doing this?</div>
<div><br></div><div>This should be used in a config like the following -</div><div> map $upstream_connecting $test {</div><div><span class="" style="white-space:pre"> </span>~^93\.184\.216\.119\: 192.168.2.40;</div>
<div><span class="" style="white-space:pre"> </span>~^192\.168\.2\.([0-9]+)\: 192.168.2.40;</div><div><span class="" style="white-space:pre"> </span>}</div><div><br></div><div> proxy_bind $test;</div><div><br></div>
<div>Regards,</div><div>Mathew</div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Nov 23, 2013 at 12:10 AM, SplitIce <span dir="ltr"><<a href="mailto:mat999@gmail.com" target="_blank">mat999@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ruslan, its funny you should mention this, I am testing a patch to do just that at the moment.<br><div><br>
</div><div>Once I am certain that its not leaking memory and I have reviewed it in regards to the nginx code standards Ill post it in this email thread in case it is of use for others.</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 11:56 PM, Ruslan Ermilov <span dir="ltr"><<a href="mailto:ru@nginx.com" target="_blank">ru@nginx.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, Nov 19, 2013 at 09:09:34PM +1030, SplitIce wrote:<br>
> An IPv6 based fallback is not the only solution we want to support,<br>
> ultimately we would like to be able to load-balance between them as well.<br>
> An error_page based solution would not assist.<br>
><br>
> I also get the feeling that such a hack would have large implications,<br>
> while either an additional parameter or another directive would be a simple<br>
> & clean solution to a real identified deficiency.<br>
><br>
> This kind of request is only going to get more common with the growing<br>
> adoption of IPv6.<br>
<br>
</div>You can make the currently selected peer address available as an nginx<br>
variable, then use the "map" directive to compute the per-peer bind<br>
address, like follows:<br>
<br>
map $peer_addr $bind_addr {<br>
192.168.1.100 192.168.1.1;<br>
2001:0db8::100 2001:0db8::1;<br>
...<br>
}<br>
<br>
or like this:<br>
<br>
map $peer_addr $bind_addr {<br>
~: 2001:0db8::1;<br>
default 192.168.1.1;<br>
}<br>
<br>
Hint: the "proxy_bind" directive supports variables.<br>
<div><div><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>