proxy_pass and trailing / decode uri

[max]

>
> 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 <mdounin at 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180312/89759867/attachment.html>