On Tue, Aug 25, 2015 at 12:35:55AM +0200, Joó Ádám wrote:

Hi there,

> The return directive allows the use of URLs relative to the server, in
> which case the scheme, server name and port are automatically
> prepended by Nginx.
>
> The port is, however, the port on which the request was received,
> which is not always the port to which the request was sent, i. e. the
> one specified in the Host header field. For example, tunneling
> nginx.org:80 through example.com:8000 a redirect will lead to
> example.com:80.
>
> Also, there is no variable exposing this value, so one must extract it
> themselves to explicitly specify in the redirect URL:

I agree that it would be nice to have the
port-specified-in-the-Host-header easily available.

Until it is, you might be able to just use $http_host directly, possibly
falling back to $host if it is empty.

(Basically, any current request that does not include a Host: header is
probably someone playing games. Sending them back a broken redirect is
possibly not a problem. If you're willing to restrict your potential
clients to "ones that send a sensible Host: header", you don't need to
worry about the fallback.)

That is, just always use

return 301 $scheme://$http_host/local;

instead of the current

return 301 /local;

(and even $scheme may be overkill, unless you use a single server{}
block for http and https.)

> Maybe this is something that would worth considering as an
> enhancement. Making return use the port in the Host header or to
> preserve backwards compatibility, introducing a switch,
> request_port_in_redirect, complementing server_name_in_redirect, off
> by default, and at the same time exposing this in a $request_port
> variable.
>
> What do you think?

I think it is probably worthwhile; and I think I won't be writing the
code to implement it ;-)

Cheers,

f
--
Francis Daly francis@daoine.org

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx