On Tue, May 24, 2022 at 01:25:05AM -0400, AussieSusan wrote:

Hi there,

> I am a total newbie to this and I don't even know if what I want to do is
> possible.

In the general case, it's not possible.

In some specific limited cases, it might work.

> For example: "https://myserver.com/weather" needs to be handled locally, but
> "https://myserver.com/whatever" needs to go to a different server on the
> network. To do this I have:
>
> location /whatever {
> proxy_pass http://10.12.45.12:1234/;
> }

Small aside -- things will work more smoothly if you have the same
number of "/" at the end of the "location" value and at the end of the
"proxy_pass" value (if you have any / in the proxy_pass value). In this
case, that would be "location /whatever/ {"

> This works OK but the pages served by the other server have relative paths
> to files that are relative to THAT server. The user's browser converts the
> relative paths from "other_base/file_path.css" to
> "https://myserver.com/other_base/file_path.css".

The simplest/cleanest fix, if you control the other "back-end" server,
is to change that server so that its content is all installed below
"/whatever/", so that your proxy_pass value does not have anything after
the host:port part and all relative links from that are equally valid
from the front-end nginx server.

The next cleanest (again, if you control the other server) is to ensure
that no things in the content that the browser will interpret as a link
start with "/". They can start with "relative", or "./relative", or maybe
"../relative" (depending how deep in the tree they are).



Although...

If the first request was for "/whatever/something", then a relative
"other/file.css" would resolve to "/whatever/other/file.css", which
should Just Work. There would be a problem if the relative link were to
"/other/file.css" -- the details there can matter :-(

So as a first attempt -- look at the html in the response, and see does
it refer to "other" or to "/other" (with a leading slash). If it does not
have the slash, then perhaps requesting /whatever/ instead of /whatever
will let things work -- and you can "enforce" that by configuring nginx
to have "location /whatever/".

> I could add another 'location' entry to my configuration for "/other_base"
> but there is no guarantee that the 'other_base" name will always be the
> same.

In general, that's the (only?) way to be sure. And it will work
fine, until more than one system wants to use the same /prefix/ or
/prefix/url.html

> What do I need to put in the Nginx configuration so that the files relative
> to the other server are correctly redirected (e.g.
> https://myserve.com/whatever/other_base/file_path.css")

Maybe just "location /whatever/ {". Maybe lots of changes elsewhere too.

Good luck with it,

f
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org