On Sat, Aug 24, 2019 at 5:18 PM Nuno Gonçalves <nunojpg@gmail.com> wrote:
>
> On Sat, Aug 24, 2019 at 8:24 AM Jeffrey 'jf' Lim <jfs.world@gmail.com> wrote:
> >
> > The host is defined by the server, surely, and not by what the client tells the server it is? And you tell the server what host it is by the server_name directive (https://nginx.org/en/docs/http/ngx_http_core_module.html#server_name).
>
> That's not correct, the server is taking the Host domain part from the
> client Host header. It's just not taking the port part.
>
> This inconsistency is why I believe it's a bug.
>
> For my exact case it was enough to set "absolute_redirect off;", since
> only the absolute redirect is affected by this issue.
>

ok this is interesting. I see "port_in_redirect" as well
(https://nginx.org/en/docs/http/ngx_http_core_module.html#port_in_redirect)
as well, but from my testing (you can also verify this in the source)
the port here would refer to the port *as specified by the server*
(specifically the listen directive), and NOT as specified by the
client in the Host header. The exception to 'port_in_redirect on'
would be if the server is listening at the standard 80; you will not
see ':80' in your redirect (i.e. no "Location:
http://example.com:80/abcd/")

When you say that "only the absolute redirect is affected by this
issue", I assume you mean that absolute redirects are affected
*because* they specify the hostname (and indirectly, the port), vs
relative redirects don't?

-jf


> Thanks,
> Nuno
>
> >
> > -jf
> >
> > On Sat, 24 Aug 2019, 01:39 Nuno Gonçalves, <nunojpg@gmail.com> wrote:
> >>
> >> I am using proxy_pass and I'm facing a issue which I'm not sure it's a bug.
> >>
> >> It is in regard to the behaviour specified by the documentation [1]:
> >>
> >> If a location is defined by a prefix string that ends with the slash
> >> character, and requests are processed by one of proxy_pass,
> >> fastcgi_pass, uwsgi_pass, scgi_pass, memcached_pass, or grpc_pass,
> >> then the special processing is performed. In response to a request
> >> with URI equal to this string, but without the trailing slash, a
> >> permanent redirect with the code 301 will be returned to the requested
> >> URI with the slash appended. If this is not desired, an exact match of
> >> the URI and location could be defined like this:
> >>
> >> Consider that there is a proxy pass for location /abcd/ { proxy_pass
> >> ... } for a server listening on port 80.
> >>
> >> If I make a request for /abcd with Host header "example.com:8080",
> >> then I receive a 301 for example.com/abcd/ and not for the expected
> >> example.com:8080/abcd/.
> >>
> >> In fact NGINX is considering the Host header domain part, but
> >> disregarding the port part.
> >>
> >> I believe this is a bug.
> >>
> >> Thanks,
> >> Nuno
> >>
> >> [1] http://nginx.org/en/docs/http/ngx_http_core_module.html
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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