Opened 6 years ago

Closed 6 years ago

#1635 closed defect (invalid)

Nginx (1.13.6) does not ignore Host Header for absoluteURI

Reported by: gspoosi@… Owned by:
Priority: minor Milestone:
Component: other Version: 1.13.x
Keywords: Cc: david.sommer@…
uname -a: Linux ipc-zbl531-a-np-09 3.10.0-862.el7.x86_64 #1 SMP Fri Apr 20 16:44:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: openresty/
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-28) (GCC)
built with OpenSSL 1.0.2k-fips 26 Jan 2017
TLS SNI support enabled
configure arguments: --prefix=/usr/local/openresty/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.3.0 --add-module=../echo-nginx-module-0.61 --add-module=../xss-nginx-module-0.06 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.32 --add-module=../form-input-nginx-module-0.12 --add-module=../encrypted-session-nginx-module-0.08 --add-module=../srcache-nginx-module-0.31 --add-module=../ngx_lua-0.10.13 --add-module=../ngx_lua_upstream-0.07 --add-module=../headers-more-nginx-module-0.33 --add-module=../array-var-nginx-module-0.05 --add-module=../memc-nginx-module-0.19 --add-module=../redis2-nginx-module-0.15 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.15 --add-module=../rds-csv-nginx-module-0.09 --add-module=../ngx_stream_lua-0.0.5 --with-ld-opt=-Wl,-rpath,/usr/local/openresty/luajit/lib --with-http_realip_module --with-stream --with-stream_ssl_module --with-http_ssl_module


If Nginx receives a request with an absolute URI it still validates the host header field and if invalid throws a 400 error. specifies:

   When a proxy receives a request with an absolute-form of
   request-target, the proxy MUST ignore the received Host header field
   (if any) and instead replace it with the host information of the
   request-target.  A proxy that forwards such a request MUST generate a
   new Host field-value based on the received request-target rather than
   forward the received Host field-value.

It is clear, that this device sends an invalid host header, but shouldn't nginx ignore the header completely according to rfc?


Frame 124: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits)
Linux cooked capture
Internet Protocol Version 4, Src:, Dst:
Transmission Control Protocol, Src Port: 45475, Dst Port: 80, Seq: 1, Ack: 1, Len: 162
Hypertext Transfer Protocol
    GET HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET HTTP/1.1\r\n]
        Request Method: GET
        Request URI:
        Request Version: HTTP/1.1
    Range: bytes=0-59\r\n
    [Full request URI:]
    [HTTP request 1/1]
    [Response in frame: 126]


Frame 126: 386 bytes on wire (3088 bits), 386 bytes captured (3088 bits)
Linux cooked capture
Internet Protocol Version 4, Src:, Dst:
Transmission Control Protocol, Src Port: 80, Dst Port: 45475, Seq: 1, Ack: 163, Len: 318
Hypertext Transfer Protocol
    HTTP/1.1 400 Bad Request\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 400 Bad Request\r\n]
        Request Version: HTTP/1.1
        Status Code: 400
        [Status Code Description: Bad Request]
        Response Phrase: Bad Request
    Date: Fri, 14 Sep 2018 12:09:22 GMT\r\n
    Content-Type: text/html\r\n
    Content-Length: 170\r\n
    Connection: close\r\n
    Server: Webproxy\r\n
    [HTTP response 1/1]
    [Time since request: 0.008412000 seconds]
    [Request in frame: 124]
    File Data: 170 bytes
Line-based text data: text/html


*23 client sent invalid host header while reading client request headers, client:, server: , request: "GET /test/pp_firmware/HD10-CH010_SUOTA.bin HTTP/1.1", host: ""

Change History (3)

comment:1 by Maxim Dounin, 6 years ago

Resolution: invalid
Status: newclosed

In terms of RFC7230, nginx is not a proxy, it is a server. Quoting the same section 5.4:

   A server MUST respond with a 400 (Bad Request) status code to any
   HTTP/1.1 request message that lacks a Host header field and to any
   request message that contains more than one Host header field or a
   Host header field with an invalid field-value.

That is, nginx is required to return 400 (Bad Request) in this case.

Not to mention that in this particular case the client clearly violates both syntax of the Host header and the requirement to use the authority component of the URI as the Host header value.

comment:2 by Victor, 6 years ago

Resolution: invalid
Status: closedreopened

in reply to:  2 comment:3 by Maxim Dounin, 6 years ago

Resolution: invalid
Status: reopenedclosed

Replying to vic210blu@…:

It makes no sense to reopening a ticket without providing an explanation on why you are doing. If you think this ticket needs to be reopened, please elaborate why do you think so.

Note: See TracTickets for help on using tickets.