handling mismatches between socket connection and host header field

[mnot]

Ted Lemon

Discuss (2013-12-18)

Point 2:

In 5.5, suppose I connect to foo.example.org on port 80, and send the following:

GET / HTTP/1.1
Host: foo.example.org:8080

This produces an effective URI of ​http://foo.example.org:8080/. What is the server supposed to do at this point? The obvious way to resolve this DISCUSS point is to update the text to address this problem. I think this example has the same property that leads you to require a 301 or 400 status in section 3.1.1.

Reported by julian.reschke@gmx.de; manually migrated from https://trac.ietf.org/trac/httpbis/ticket/550

[mnot]

From [2587]:

Use factual phrasing for reconstructing an effective request URI instead of a MUST; see #531

Update the description of constructing the effective request URI such that it defers to local configuration.

Add a paragraph about the need for an origin server to verify that the constructed URI is consistent with the connection context, and point to (not yet complete) security considerations on routing; see #550

[mnot]

Comment from fielding@gbiv.com:

This has been addressed by the following text added to 5.5 (Effective Request URI):

   Once the effective request URI has been constructed, an origin server
   needs to decide whether or not to provide service for that URI via
   the connection in which the request was received.  For example, the
   request might have been misdirected, deliberately or accidentally,
   such that the information within a received request-target or Host
   header field differs from the host or port upon which the connection
   has been made.  If the connection is from a trusted gateway, that
   inconsistency might be expected; otherwise, it might indicate an
   attempt to bypass security filters, trick the server into delivering
   non-public content, or poison a cache.  See Section 9 for security
   considerations regarding message routing.