<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi Francis.<br><br></div>Thanks for your detailed analysis.<br><br></div>Unfortunately, our backen-service(s) (on port 2000 in the example) is ssh-reverse-tunnel, having two layers of machines behind them. The terminating-node for sure cannot be changed.<br><br></div>Looking at your explanations, I guess then we will have to open a port for every service.<br></div>So, for example, port 2001 for proxying to service running on ssh-tunnel at 2000,<br></div> port 2003 for proxying to service running on ssh-tunnel at 2002, and so on.<br><br><br></div>That brings me to my last question as per <a href="http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html">http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html</a>. If there isn't an issue with opening multiple nginx-listening-ports to the public, then I guess we are done.<br><br><br></div>Would love to hear back your thoughts.<br><br><br><br></div>Thanks and Regards,<br></div>Ajay<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 9, 2017 at 4:19 PM, Francis Daly <span dir="ltr"><<a href="mailto:francis@daoine.org" target="_blank">francis@daoine.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Apr 08, 2017 at 06:39:59PM +0530, Ajay Garg wrote:<br>
<br>
Hi there,<br>
<span class=""><br>
> However, I am not able to do the proxying if I perform url-rewriting.<br>
> Nothing of the following works ::<br>
<br>
</span>Note that if you want to reverse-proxy a back-end web service at a<br>
different part of the url hierarchy to where it believes it is installed,<br>
in general you need the web service to help.<br>
<br>
That is, if you want the back-end / to correspond to the front-end /x/,<br>
then if the back-end ever links to something like /a, you will need that<br>
to become translated to /x/a before it leaves the front-end. In general,<br>
the front-end cannot do that translation.<br>
<br>
So you may find it easier to configure the back-end to be (or to act as<br>
if it is) installed below /x/ directly.<br>
<br>
Otherwise things can go wrong.<br>
<br>
What that means is...<br>
<br>
> a)<br>
<span class="">> server {<br>
> listen 2001;<br>
> location /78 {<br>
><br>
> auth_basic 'Restricted';<br>
> auth_basic_user_file<br>
> /home/<wbr>2819163155b64c4c81f8608aa23c9f<wbr>aa/.htpasswd;<br>
> proxy_pass <a href="http://127.0.0.1:2000" rel="noreferrer" target="_blank">http://127.0.0.1:2000</a>;<br>
> }<br>
> }<br>
> ##############################<wbr>##############################<wbr>################<br>
><br>
> No URL change happens, and 404 (illegal-file-access) is obtained.<br>
<br>
</span>If you request <a href="http://1.2.3.4:2001/78" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78</a>, nginx should request<br>
<a href="http://127.0.0.1:2000/78" rel="noreferrer" target="_blank">http://127.0.0.1:2000/78</a>, and I guess that the back-end said 404.<br>
<br>
What do the back-end logs say?<br>
<br>
Can you show a specific "curl" command, with "-v" or "-i", that you can<br>
use to show this error case?<br>
<span class=""><br>
> b)<br>
> ##############################<wbr>##############################<wbr>################<br>
> server {<br>
> listen 2001;<br>
> location /78 {<br>
><br>
> auth_basic 'Restricted';<br>
> auth_basic_user_file<br>
> /home/<wbr>2819163155b64c4c81f8608aa23c9f<wbr>aa/.htpasswd;<br>
> proxy_pass <a href="http://127.0.0.1:2000/" rel="noreferrer" target="_blank">http://127.0.0.1:2000/</a>;<br>
> }<br>
> }<br>
> ##############################<wbr>##############################<wbr>################<br>
><br>
> No URL change happens, and 404 (illegal-file-access) is obtained.<br>
<br>
</span>If you request <a href="http://1.2.3.4:2001/78" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78</a>, nginx should request<br>
<a href="http://127.0.0.1:2000/" rel="noreferrer" target="_blank">http://127.0.0.1:2000/</a>. Does the 404 come from nginx or the back-end?<br>
<br>
What do the back-end logs say?<br>
<br>
(Did you request <a href="http://1.2.3.4:2001/78" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78</a>, or <a href="http://1.2.3.4:2001/78/" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78/</a> --<br>
because the two urls arl different.)<br>
<span class=""><br>
> c)<br>
> ##############################<wbr>##############################<wbr>################<br>
> server {<br>
> listen 2001;<br>
> location /78/ {<br>
><br>
> auth_basic 'Restricted';<br>
> auth_basic_user_file<br>
> /home/<wbr>2819163155b64c4c81f8608aa23c9f<wbr>aa/.htpasswd;<br>
> proxy_pass <a href="http://127.0.0.1:2000/" rel="noreferrer" target="_blank">http://127.0.0.1:2000/</a>;<br>
> }<br>
> }<br>
> ##############################<wbr>##############################<wbr>################<br>
><br>
> The URL does changes from <a href="http://1.2.3.4:2001/78" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78</a> to<br>
> <a href="http://1.2.3.4:2001/cgi-bin/webproc" rel="noreferrer" target="_blank">http://1.2.3.4:2001/cgi-bin/<wbr>webproc</a>, but a 404 is obtained.<br>
<br>
</span>If you request <a href="http://1.2.3.4:2001/78" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78</a>, nginx should return 301<br>
redirecting you to <a href="http://1.2.3.4:2001/78/" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78/</a>. If you then request<br>
<a href="http://1.2.3.4:2001/78/" rel="noreferrer" target="_blank">http://1.2.3.4:2001/78/</a>, nginx should request <a href="http://127.0.0.1:2000/" rel="noreferrer" target="_blank">http://127.0.0.1:2000/</a>. I<br>
guess that the back-end then returns 301 redirecting you to<br>
/cgi-bin/webproc. If you request <a href="http://1.2.3.4:2001/cgi-bin/webproc" rel="noreferrer" target="_blank">http://1.2.3.4:2001/cgi-bin/<wbr>webproc</a>,<br>
then nginx should return 404 (because /cgi-bin/webproc does not start<br>
with /78/).<br>
<br>
Can you see all of those requests and responses, especially the ones<br>
involving the back-end?<br>
<span class=""><br>
> d)<br>
> ##############################<wbr>##############################<wbr>################<br>
> server {<br>
> listen 2001;<br>
> location /78/ {<br>
><br>
> auth_basic 'Restricted';<br>
> auth_basic_user_file<br>
> /home/<wbr>2819163155b64c4c81f8608aa23c9f<wbr>aa/.htpasswd;<br>
> proxy_pass <a href="http://127.0.0.1:2000" rel="noreferrer" target="_blank">http://127.0.0.1:2000</a>;<br>
> }<br>
> }<br>
> ##############################<wbr>##############################<wbr>################<br>
><br>
> No URL change happens, and 404 (illegal-file-access) is obtained.<br>
<br>
</span>Similar to a)<br>
<span class=""><br>
> So, I guess c) is the closest to doing a url-rewrite, but I wonder why am I<br>
> getting a 404, even though the URL-change is perfect.<br>
<br>
</span>You have multiple possible configurations there. And you have not shown<br>
the details of the requests and responses.<br>
<br>
Can you show some requests that you want the client to make of nginx,<br>
and then show the matching requests that you want nginx to make of<br>
the back-end?<br>
<br>
You can use "curl" on the nginx machine to make similar requests of the<br>
back-end yourself, to see that actual response details. That might give<br>
a hint as to what, if any, proxy_redirect directives are needed.<br>
<br>
> Any ideas please?<br>
<br>
Can you configure the web service on port 2000 to believe that all of<br>
its useful urls are below /78/ ? If so, use configuration d).<br>
<span class="HOEnZb"><font color="#888888"><br>
f<br>
--<br>
Francis Daly <a href="mailto:francis@daoine.org">francis@daoine.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Regards,<br>Ajay<br></div>
</div>