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 fran...@daoine.org _______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org
