URL-Rewriting not working
Ajay Garg
ajaygargnsit at gmail.com
Sun Apr 9 11:57:31 UTC 2017
Hi Francis.
Thanks for your detailed analysis.
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.
Looking at your explanations, I guess then we will have to open a port for
every service.
So, for example, port 2001 for proxying to service running on ssh-tunnel at
2000,
port 2003 for proxying to service running on
ssh-tunnel at 2002, and so on.
That brings me to my last question as per
http://mailman.nginx.org/pipermail/nginx/2017-April/053448.html. If there
isn't an issue with opening multiple nginx-listening-ports to the public,
then I guess we are done.
Would love to hear back your thoughts.
Thanks and Regards,
Ajay
On Sun, Apr 9, 2017 at 4:19 PM, Francis Daly <francis at daoine.org> wrote:
> On Sat, Apr 08, 2017 at 06:39:59PM +0530, Ajay Garg wrote:
>
> Hi there,
>
> > However, I am not able to do the proxying if I perform url-rewriting.
> > Nothing of the following works ::
>
> Note that if you want to reverse-proxy a back-end web service at a
> different part of the url hierarchy to where it believes it is installed,
> in general you need the web service to help.
>
> That is, if you want the back-end / to correspond to the front-end /x/,
> then if the back-end ever links to something like /a, you will need that
> to become translated to /x/a before it leaves the front-end. In general,
> the front-end cannot do that translation.
>
> So you may find it easier to configure the back-end to be (or to act as
> if it is) installed below /x/ directly.
>
> Otherwise things can go wrong.
>
> What that means is...
>
> > a)
> > server {
> > listen 2001;
> > location /78 {
> >
> > auth_basic 'Restricted';
> > auth_basic_user_file
> > /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
> > proxy_pass http://127.0.0.1:2000;
> > }
> > }
> > ############################################################
> ################
> >
> > No URL change happens, and 404 (illegal-file-access) is obtained.
>
> If you request http://1.2.3.4:2001/78, nginx should request
> http://127.0.0.1:2000/78, and I guess that the back-end said 404.
>
> What do the back-end logs say?
>
> Can you show a specific "curl" command, with "-v" or "-i", that you can
> use to show this error case?
>
> > b)
> > ############################################################
> ################
> > server {
> > listen 2001;
> > location /78 {
> >
> > auth_basic 'Restricted';
> > auth_basic_user_file
> > /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
> > proxy_pass http://127.0.0.1:2000/;
> > }
> > }
> > ############################################################
> ################
> >
> > No URL change happens, and 404 (illegal-file-access) is obtained.
>
> If you request http://1.2.3.4:2001/78, nginx should request
> http://127.0.0.1:2000/. Does the 404 come from nginx or the back-end?
>
> What do the back-end logs say?
>
> (Did you request http://1.2.3.4:2001/78, or http://1.2.3.4:2001/78/ --
> because the two urls arl different.)
>
> > c)
> > ############################################################
> ################
> > server {
> > listen 2001;
> > location /78/ {
> >
> > auth_basic 'Restricted';
> > auth_basic_user_file
> > /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
> > proxy_pass http://127.0.0.1:2000/;
> > }
> > }
> > ############################################################
> ################
> >
> > The URL does changes from http://1.2.3.4:2001/78 to
> > http://1.2.3.4:2001/cgi-bin/webproc, but a 404 is obtained.
>
> If you request http://1.2.3.4:2001/78, nginx should return 301
> redirecting you to http://1.2.3.4:2001/78/. If you then request
> http://1.2.3.4:2001/78/, nginx should request http://127.0.0.1:2000/. I
> guess that the back-end then returns 301 redirecting you to
> /cgi-bin/webproc. If you request http://1.2.3.4:2001/cgi-bin/webproc,
> then nginx should return 404 (because /cgi-bin/webproc does not start
> with /78/).
>
> Can you see all of those requests and responses, especially the ones
> involving the back-end?
>
> > d)
> > ############################################################
> ################
> > server {
> > listen 2001;
> > location /78/ {
> >
> > auth_basic 'Restricted';
> > auth_basic_user_file
> > /home/2819163155b64c4c81f8608aa23c9faa/.htpasswd;
> > proxy_pass http://127.0.0.1:2000;
> > }
> > }
> > ############################################################
> ################
> >
> > No URL change happens, and 404 (illegal-file-access) is obtained.
>
> Similar to a)
>
> > So, I guess c) is the closest to doing a url-rewrite, but I wonder why
> am I
> > getting a 404, even though the URL-change is perfect.
>
> You have multiple possible configurations there. And you have not shown
> the details of the requests and responses.
>
> Can you show some requests that you want the client to make of nginx,
> and then show the matching requests that you want nginx to make of
> the back-end?
>
> You can use "curl" on the nginx machine to make similar requests of the
> back-end yourself, to see that actual response details. That might give
> a hint as to what, if any, proxy_redirect directives are needed.
>
> > Any ideas please?
>
> Can you configure the web service on port 2000 to believe that all of
> its useful urls are below /78/ ? If so, use configuration d).
>
> f
> --
> Francis Daly francis at daoine.org
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
--
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20170409/a714467b/attachment-0001.html>
More information about the nginx
mailing list