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