3.2. <del> A client that makes a request for an "http" URI without prior knowledge about support for HTTP/2 on the next hop uses the HTTP Upgrade mechanism (HTTP).  The client does so by making an HTTP/1.1 request that includes an Upgrade header field with the "h2c" token. Such an HTTP/1.1 request MUST include exactly one Http2SettingsHeader header field. For example: Requests that contain message content MUST be sent in their entirety before the client can send HTTP/2 frames.  This means that a large request can block the use of the connection until it is completely sent. If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to HTTP/2, at the cost of an additional round trip. A server that does not support HTTP/2 can respond to the request as though the Upgrade header field were absent: A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as described in discover-https. A server that supports HTTP/2 accepts the upgrade with a 101 (Switching Protocols) response.  After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames.  These frames MUST include a response to the request that initiated the upgrade. For example: The first HTTP/2 frame sent by the server MUST be a server connection preface (ConnectionHeader) consisting of a SETTINGS frame (SETTINGS). Upon receiving the 101 response, the client MUST send a ConnectionHeader, which includes a SETTINGS frame. The HTTP/1.1 request that is sent prior to upgrade is assigned a stream identifier of 1 (see StreamIdentifiers).  Stream 1 is implicitly "half-closed" from the client toward the server (see StreamStates), since the request is completed as an HTTP/1.1 request. After commencing the HTTP/2 connection, stream 1 is used for the response. 3.2.1. A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one header field.  The header field is a connection-specific header field that includes settings that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present.  A server MUST NOT send this header field. The content of the header field is the frame payload of a SETTINGS frame (SETTINGS), encoded as a base64url string (that is, the URL- and filename-safe Base64 encoding described in RFC4648, with any trailing '=' characters omitted).  The RFC5234 production for is defined in HTTP. Since the upgrade is only intended to apply to the immediate connection, a client sending the header field MUST also send as a connection option in the header field to prevent it from being forwarded (see HTTP). A server decodes and interprets these values as it would any other SETTINGS frame.  Explicit SettingsSync is not necessary, since a 101 response serves as implicit acknowledgement.  Providing these values in the upgrade request gives a client an opportunity to provide settings prior to receiving any frames from the server. 3.3. </del> A client that makes a request to an "https" URI uses TLS13 with the TLS-ALPN.