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:
set $is_port '';
set $port '';
if ($http_host ~ :(\d+)$) {
set $is_port ':';
set $port $1;
}
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.
On Tue, Aug 25, 2015 at 12:35:55AM +0200, Jo dm wrote:
Hi there,
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
