On Sat, Aug 24, 2019 at 5:18 PM Nuno Gonçalves <nuno...@gmail.com> wrote: > > On Sat, Aug 24, 2019 at 8:24 AM Jeffrey 'jf' Lim <jfs.wo...@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, <nuno...@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