3. Background

この節では optimistic HTTP/1.1 protocol transitions の RFC 原文を保持し, request smuggling risks, parser exploit risks, existing Upgrade tokens, HTTP CONNECT requirements, IANA status を含めます.

3.  Background

   In HTTP/1.1 [HTTP/1.1] and later, a single connection can be used for
   many requests.  In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], these
   requests can be multiplexed, as each request is distinguished
   explicitly by its stream ID.  However, in HTTP/1.1, requests are
   strictly sequential, and each new request is distinguished implicitly
   by the closure of the preceding request.

   HTTP/1.1 is also the only version of HTTP that allows the client to
   change the protocol used for the remainder of the connection.  There
   are two mechanisms to request such a protocol transition.  One
   mechanism is the Upgrade header field ([HTTP], Section 7.8).  When
   included in a request, this field indicates that the client would
   like to use this connection for a protocol other than HTTP/1.1.  The
   server replies with a 101 (Switching Protocols) status code if it
   accepts the protocol change ([HTTP], Section 15.2.2).

   The other mechanism is the HTTP CONNECT method (Section 9.3.6 of
   [HTTP]).  This method indicates that the client wishes to establish a
   TCP connection to the specified host and port.  If accepted, the
   server replies with a 2xx (Successful) response to indicate that the
   request was accepted and a TCP connection was established.  After
   this point, the TCP connection is acting as a TCP tunnel, not an
   HTTP/1.1 connection.

   Both of these mechanisms also permit the server to reject the
   request.  For example, Section 7.8 of [HTTP] says:

   |  A server MAY ignore a received Upgrade header field if it wishes
   |  to continue using the current protocol on that connection.

   and Section 9.3.6 of [HTTP] says:

   |  A server MUST reject a CONNECT request that targets an empty or
   |  invalid port number, typically by responding with a 400 (Bad
   |  Request) status code.

   Rejected upgrades are common and can happen for a variety of reasons,
   such as:

   *  The server does not support any of the client's indicated upgrade
      tokens (i.e., the client's proposed new protocols), so it
      continues to use HTTP/1.1.

   *  The server knows that an upgrade to the offered protocol will not
      provide any improvement over HTTP/1.1 for this request to this
      resource, so it chooses to respond in HTTP/1.1.

   *  The server requires the client to authenticate before upgrading
      the protocol, so it replies with the status code 401
      (Authentication Required) and provides a challenge in an
      Authorization response header field ([HTTP], Section 11.6.2).

   *  The resource has moved, so the server replies with a 3xx
      (Redirection) status code ([HTTP], Section 3.4).

   Similarly, servers frequently reject HTTP CONNECT requests, such as
   when:

   *  The server does not support HTTP CONNECT.

   *  The specified destination is not allowed under server policy.

   *  The destination cannot be resolved, is unreachable, or does not
      accept the connection.

   *  The proxy requires the client to authenticate before proceeding.

   After rejecting a request, the server will continue to interpret
   bytes received on that connection in accordance with HTTP/1.1.

   Section 7.8 of [HTTP] also states:

   |  A client cannot begin using an upgraded protocol on the connection
   |  until it has completely sent the request message (i.e., the client
   |  can't change the protocol it is sending in the middle of a
   |  message).

   In other words, completion of the request message is a *necessary*
   condition for the client to begin using the new protocol.  However,
   it is important to clarify that this is not a *sufficient* condition
   because the server might reject the request.

   In some cases, the client might predict that the server is likely to
   accept a requested protocol transition.  For example, if a request
   using an upgrade token recently succeeded, the client might expect
   that subsequent requests with the same upgrade token will also
   succeed.  If this expectation is correct, the client can often reduce
   delay by immediately sending the first bytes of the new protocol
   "optimistically", without waiting for the server's response.  This
   document explores the security implications of this "optimistic"
   behavior.