Opened 7 years ago

Closed 7 years ago

#550 closed design (incorporated)

handling mismatches between socket connection and host header field

Reported by: julian.reschke@… Owned by: http://datatracker.ietf.org/doc/draft-ietf-httpbis-p1-messaging/ballot/
Priority: normal Milestone: 26
Component: p1-messaging Severity: In IESG Evaluation
Keywords: Cc:

Description

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.

Change History (4)

comment:1 Changed 7 years ago by julian.reschke@…

  • Summary changed from handling mismatches between socket cnnection and host header field to handling mismatches between socket connection and host header field

comment:2 Changed 7 years ago by fielding@…

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

comment:3 Changed 7 years ago by fielding@…

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.

comment:4 Changed 7 years ago by fielding@…

  • Resolution set to incorporated
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.