> > Whether this is correct or no depends on the particular setup - in > particular, it depends on what your backend expects as an URI. If > your backend is picky about specific forms of encoding, preserving > full original URI might be much better option than trying to > invent hacky workarounds like the one you've linked. Obviously > enough, this might either envolve re-configuring the backend to > accept full original URIs, or hosting things on a dedicated > domain. > Yes sub-domains would be the best option but I'm already listening on sub-domain and do not want to make an other sub-level. I cannot configure my backends (several backends) to be able to listen on /api, this is exactly why I needed to use Nginx as reverse proxy.
2018-03-12 13:28 GMT+01:00 Maxim Dounin <mdou...@mdounin.ru>: > Hello! > > On Mon, Mar 12, 2018 at 09:55:15AM +0100, max wrote: > > > > When you want nginx to replace matching part of the URI with "/", > > > it will do so on the decoded/normalized URI, and will re-encode > > > special characters in what's left. > > > > > > If you want nginx to preserve original URI as sent by the client, > > > consider using proxy_pass without the URI part. That is, > > > instead of > > > > > > proxy_pass http://127.0.0.1:82/; > > > > > > use > > > > > > proxy_pass http://127.0.0.1:82; > > > > > > Note no trailing "/". This way the original URI as sent by the > > > client will be preserved without any modifications. > > > > > > > > > Thank you for your answer but it is not correct for location different > than > > '/'. With your proposal, targeting http://domain1.com/api/foo/bar, > socket > > on port 82 receives: /api/foo/bar. I guess the only way to remove the > /api > > part is "rewrite" and involves re-encoding... > > Whether this is correct or no depends on the particular setup - in > particular, it depends on what your backend expects as an URI. If > your backend is picky about specific forms of encoding, preserving > full original URI might be much better option than trying to > invent hacky workarounds like the one you've linked. Obviously > enough, this might either envolve re-configuring the backend to > accept full original URIs, or hosting things on a dedicated > domain. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > 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
