Nginx (1.13.6) does not ignore Host Header for absoluteURI

[gspoosi@…]

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

​https://tools.ietf.org/html/rfc7230#section-5.4 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?

Example:

Frame 124: 230 bytes on wire (1840 bits), 230 bytes captured (1840 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 176.127.60.77, Dst: 47.91.89.38
Transmission Control Protocol, Src Port: 45475, Dst Port: 80, Seq: 1, Ack: 1, Len: 162
Hypertext Transfer Protocol
    GET http://hd10.vtech.com/test/pp_firmware/HD10-CH010_SUOTA.bin HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): GET http://hd10.vtech.com/test/pp_firmware/HD10-CH010_SUOTA.bin HTTP/1.1\r\n]
        Request Method: GET
        Request URI: http://hd10.vtech.com/test/pp_firmware/HD10-CH010_SUOTA.bin
        Request Version: HTTP/1.1
    Host: http://hd10.vtech.com/test/pp_firmware/HD10-CH010_SUOTA.bin\r\n
    Range: bytes=0-59\r\n
    \r\n
    [Full request URI: http://hd10.vtech.com/test/pp_firmware/HD10-CH010_SUOTA.bin]
    [HTTP request 1/1]
    [Response in frame: 126]
TRANSUM RTE Data

Response:

Frame 126: 386 bytes on wire (3088 bits), 386 bytes captured (3088 bits)
Linux cooked capture
Internet Protocol Version 4, Src: 47.91.89.38, Dst: 176.127.60.77
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
    \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

nginx.log:

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

[Maxim Dounin]

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.

[Maxim Dounin]

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.