通常来说这一机制总是由客户端发起的 （不过也有例外，比如说可以由服务端发起升级到传输层安全协议（TLS））， 服务端可以选择是否要升级到新协议。借助这一技术，连接可以以常用的协议启动（如HTTP/1.1），随后再升级到HTTP2甚至是WebSockets.
GET /index.html HTTP/1.1 Host: www.example.com Connection: upgrade Upgrade: example/1, foo/2
至今为止最经常会需要升级一个HTTP连接的场合就是使用WebSocket。当你用 WebSocket API 以及其他大部分实现WebSockets的库去建立WebSocket连接时，基本上都不用操心升级的过程，因为这些API已经实现了这一步。比如，用如下API打开一个WebSocket连接：
webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");
WebSocket() 构造函数已经自动完成了发送初始 HTTP/1.1 请求，处理握手及升级过程。
Connection: Upgrade Upgrade: websocket
- 指需要(或支持)的扩展的逗号分隔列表。这些值来自IANA WebSocket 扩展名注册表。带参数的扩展使用分号表示。
Sec-WebSocket-Extensions: superspeed, colormode; depth=16
Provides information to the server which is needed in order to confirm that the client is entitled to request an upgrade to WebSocket. This header can be used when insecure (HTTP) clients wish to upgrade, in order to offer some degree of protection against abuse. The value of the key is computed using an algorithm defined in the WebSocket specification, so this does not provide security. Instead, it helps to prevent non-WebSocket clients from inadvertently, or through misuse, requesting a WebSocket connection. In essence, then, this key simply confirms that "Yes, I really mean to open a WebSocket connection."
This header is automatically added by clients that choose to use it; it cannot be added using the
- The key for this request to upgrade. The client adds this if it wishes to do so, and the server will include in the response a key of its own, which the client will validate before delivering the upgrade reponse to you.
The server's response's
Sec-WebSocket-Accept header will have a value computed based upon the specified
Sec-WebSocket-Protocol header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a
Sec-WebSocket-Protocol header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.
- A comma-separated list of subprotocol names, in the order of preference. The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server.
Specifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.
- The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the IANA WebSocket Version Number Registry. The most recent final version of the WebSocket protocol is version 13.
If the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a
Sec-WebSocket-Version header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no
Sec-WebSocket-Version header is included in the response.
- A comma-delineated list of the WebSocket protocol versions supported by the server.
The response from the server may include these.
Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the repsonse headers.
- If a
Sec-WebSocket-Keyheader was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the SHA-1 hash of that concatenated string, resulting in a 20-byte value. That value is then base64 encoded to obtain the value of this property.
You can also upgrade an HTTP/1.1 connection to TLS/1.0. The main advantages to this are that you can avoid using URL redirection from "http://" to "https://" on the server and you can easily use TLS on virtual hosts. This may, however, introduce problems with proxy servers.
Upgrading an HTTP connection to use TLS uses the Upgrade (en-US) header with the token
"TLS/1.0". If the switch is made successfully, the original request (which included
Upgrade) is completed as normal, but on the TLS connection.
The request to TLS can be made either optionally or mandatorily.
To upgrade to TLS optionally (that is, allowing the connection to continue in cleartext if the upgrade to TLS fails), you simply use the
Connection headers as expected. For example, given the original request:
GET http://destination.server.ext/secretpage.html HTTP/1.1 Host: destination.server.ext Upgrade: TLS/1.0 Connection: Upgrade
If the server does not support TLS upgrade, or is unable to upgrade to TLS at the time, it responds with a standard HTTP/1.1 response, such as:
HTTP/1.1 200 OK Date: Thu, 17 Aug 2017 21:07:44 GMT Server: Apache Last-Modified: Thu, 17 Aug 2017 08:30:15 GMT Content-Type: text/html; charset=utf-8 Content-Length: 31374 <html> ... </html>
If the server does support TLS upgrade and wishes to permit the upgrade, it responds with the
"101 Switching Protocols" response code, like this:
HTTP/1.1 101 Switching Protocols Upgrade: TLS/1.0, HTTP/1.1
Once the TLS handshake is complete, the original request will be responded to as normal.
To request a mandatory upgrade to TLS—that is, to upgrade and fail the connection if the upgrade is not successful—your first request must be an
OPTIONS request, like this:
OPTIONS * HTTP/1.1 Host: destination.server.ext Upgrade: TLS/1.0 Connection: Upgrade
If the upgrade to TLS succeeds, the server will respond with
"101 Switching Protocols" as described in the previous section. If the upgrade fails, the HTTP/1.1 connection will fail.
This works roughly the same way as a client-initiated upgrade; an optional upgrade is requested by adding the Upgrade (en-US) header to any message. A mandatory upgrade, though, works slightly differently, in that it requests the upgrade by replying to a message it receives with the
426 status code, like this:
HTTP/1.1 426 Upgrade Required Upgrade: TLS/1.1, HTTP/1.1 Connection: Upgrade <html> ... Human-readable HTML page describing why the upgrade is required and what to do if this text is seen ... </html>
If the client receiving the
"426 Upgrade Required" response is willing and able to upgrade to TLS, it should then start the same process covered above under Client-initiated upgrade to HTTP over TLS.