Yes you can but you need to rewrite the text as it passes through nginx using a sub_filter. It isn't that hard but it is tedious.
/Michael Salmon
> On 9 May 2017, at 01:18, deoren <nginx-users-list@whyaskwhy.org> wrote:
>
> Hi,
>
> Thanks for reading this.
>
> My apologies if this has been answered before, but after much reading (official docs, mailing list discussions, etc.) I'm still not completely clear on whether this is supported. I know it's a hangup on my part, but I've not managed to get past the stumbling point yet.
>
> #1) Have a web app answer to https://subdomain.example.com/ with app related urls like '/login', '/issues', and requests for static resources with URL paths like '/static/styles.css'. The app runs on localhost at http://127.0.0.1:3000 and is proxied by nginx with a direct mapping of http://subdomain.example.com/ to http://127.0.0.1:3000/ and it works well. As indicated, this setup does not use a sub-URI, but treats '/' as its root URL path.
>
> #2) I'd like to move the web application to https://subdomain.example.com/sub-uri/ by setting up location block like so (spacing condensed for display purposes):
>
> location /flask-demo {
> root /var/www/passenger-python-flask-demo;
> proxy_set_header X-Forwarded-Proto $scheme;
> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
> proxy_set_header X-Forwarded-Host $host;
> proxy_pass http://127.0.0.1:3000/;
> }
>
> The trailing slash was added in an attempt to map /flask-demo/SOMETHING to /SOMETHING in the application's point of view.
>
> That works well for a test web app where everything is contained in a single file, but when the static assets are referenced by the HTML output the user's browser attempts to pull static content from '/' instead of '/flask-demo/'.
>
> I've found that for this and other web applications (demo and production) that I've tested thus you can configure the base URL in the web application itself.
>
> Does nginx support redirecting those requests for static resources requests to the associated sub-URI without modifying the web application? If it was only one web application I could setup location blocks for specific patterns, but if I plan on running multiple web applications on a single FQDN (perhaps even different instances of the same web app), each in a separate sub-URI, those web applications might all make requests to '/static/styles.css' based on their original configuration.
>
> I'm hoping there is a way to isolate each web application based on the initial location block match, thereby catching follow-up requests for static resources related to the first request and prepend the sub-URI. Thus a request for '/static/styles.css' becomes '/flask-demo/static/styles.css' if I visit '/flask-demo' and if I visit '/other-app' the static request becomes '/other-app/static/styles.css', all without modifying the web application to know it is being run from a sub-URI.
>
> I assume the answer is "no, this is not supported", but I wanted to ask just to make sure I'm not overlooking something. Francis Daly's remarks on the "URL-Rewriting not working" thread that I've quoted from below seems to suggest it might be possible, but probably isn't worth the headache:
>
> > 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.
>
> I found the 'proxy_redirect' directive, but it doesn't appear to do what I'm looking for. Instead, it appears to be designed specifically to do things like prevent having the client access http://127.0.0.1:3000/ instead of http://127.0.0.1:80/ (as is shown in my example).
>
> I've used nginx for years, but only in very basic configurations. This is something new to me and I'm struggling to wrap my head around it. Thank you for reading this and any advice you can offer.
> _______________________________________________
> nginx mailing list
> nginx@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
