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 <sa...@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/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
