proxy_pass works on main page but not other pages

[Francis Daly]

On Sun, Oct 30, 2022 at 11:56:39AM -0600, Brian Carey wrote:

Hi there,

> Thinking it through though I think my solution is bad since it implies a
> dependency between the urls defined in the program and the location used in
> nginx, ie. they must match and the program cannot be proxied at an arbitrary
> location.

if you have a "back-end" at http://one.internal.example.com/, that is
reverse-proxied behind the public-facing http://example.com/one/ using
the "normal" nginx config fragment

    location /one/ { proxy_pass http://one.internal.example.com/; }

then the client browser making the requests does not know that there is
a back-end service.

When the client requests http://example.com/one/two.html, nginx will
ask for http://one.internal.example.com/two.html, and will send the
response http headers and body content back to the client.

If that response contains links or references of the form "three.jpg"
or "./three.jpg", then the client will make the next request for
http://example.com/one/three.jpg, which will get to nginx, which will know
to proxy_pass to the same back-end service, and all will probably work.

If the response contains links of the form "/three.jpg", then the
client will make the next request for http://example.com/three.jpg,
which will get to nginx but will probably not get a useful response,
because nginx knows that it must not proxy_pass to the same back-end
because the local part of the request does not start with /one/. The
user will probably see an error or something that looks broken.

If the response contains links of the form
http://one.internal.example.com/three.jpg, then the client will presumably
fail to resolve the hostname one.internal.example.com, and the user will
probably see an error.

> So hopefully there is a better solution than the one I found. I
> hope I'm not asking too many questions.

Whether or not a particular back-end can be reverse-proxied easily,
or can be reverse-proxied easily at a different local part of the url
hierarchy from where it thinks it is installed, it mostly down to the
back-end application to decide.

In general (and there are exceptions), nginx can readily rewrite the
http response headers, and cannot readily rewrite the http response body,
in order to adjust links or references to other internal resources.

If you control the back-end service, and you know that you want to
reverse-proxy it behind http://example.com/one/, you will probably
find it easier to work with, if you can install the back-end service
at http://one.internal.example.com/one/.

That would make the first two forms of links "Just Work"; and the third
(full-url) form is usually easier to recognise and replace.

> > > I am able to use proxy_pass to forward https:/biscotty.me/striker to
> > > the main page of my app. The problem is that all of the links in the
> > > app result in a page not found error from the apache server handling
> > > requests to /. So it seems like the port number information is
> > > somehow being lost in translation?

More likely, I guess, is that the links are of the second form, to
"/three.jpg" instead of the "three.jpg".

But it could also be related to what the initial request from the client
was -- "/striker" and "/striker/" are different, and I suspect you should
use the with-trailing-slash version in your config "location" line.

But if you already have a working configuration, that's good!

Cheers,

	f
-- 
Francis Daly        francis at daoine.org