Add directive to allow underscores in hostnames

[Maxim Dounin]

Hello!

On Wed, Nov 16, 2016 at 06:36:12PM -0600, Aleksandr Kupriyanov wrote:

> <http://www.google.com/url?q=http%3A%2F%2Fwww.instartlogic.com%2F&sa=D&sntz=1&usg=AFrqEzc4puDXYOgyifEWrSJrJIfW1sViFg>

> # HG changeset patch
> # User Aleksandr Kupriyanov <sasha at instartlogic.com>
> # Date 1479340749 21600
> # Node ID af947b854971993f318417c70c3818147b320a0d
> # Parent  6a26016e9a138102798a7ec3e74747fbd6018f82
> Add directive to allow underscores in hostnames
> 
> Two equivalent requests generate different responses:
> 
> 1. ---------------
> GET http://host_1.home/ HTTP/1.1
> Host: host_1.home
> ...
> HTTP/1.1 400 Bad Request
> Server: nginx/1.X.XX
> ------------------
> 
> 2. ---------------
> GET / HTTP/1.1
> Host: host_1.home
> ...
> HTTP/1.1 200 OK
> Server: nginx/1.X.XX
> ------------------
> 
> To avoid that a new directive is proposed:
> 
> Syntax: underscores_in_hostname on | off;
> Default: underscores_in_headers off;
> Context: http, server
> 
> Enables or disables the use of underscores in host names of
> client request line.
> 
> See a discussion about underscores in DNS here:
> http://domainkeys.sourceforge.net/underscore.html

Shouldn't we just allow underscores in 
ngx_http_parse_request_line() instead?  It doesn't looks like 
there are reasons to keep the test that strict.

In case of underscores_in_headers there a clear security reason: 
headers are exposed via the HTTP_* variables in CGI, and via 
$http_* variables in nginx itself, and this makes headers with 
underscores indistinguishable from ones with dash, and creates an 
attack vector.

I don't see such a problem with underscores in hostname when it's 
passed via the request line - especially keeping in mind that we 
don't enforce such a limitation via the Host header.

-- 
Maxim Dounin
http://nginx.org/