HTTP Protocol Upgrade Mechanism
The HTTP/1.1 protocol upgrade mechanism allows an active connection to switch from HTTP to a different protocol. The mechanism uses the Upgrade and Connection headers to negotiate a protocol change without closing the existing connection. In practice, WebSocket is the primary protocol negotiated through this mechanism.
Usage
A protocol upgrade starts when the client sends
an HTTP/1.1 request with the
Upgrade header listing one or more
desired protocols. The Connection
header must include the Upgrade token because
Upgrade is a hop-by-hop header.
The server is free to ignore the upgrade request. Supporting a protocol does not oblige the server to accept the switch. When the server agrees, the response is 101 Switching Protocols with the selected protocol in the Upgrade header. The original HTTP request continues under the new protocol once the switch completes.
When the server ignores the Upgrade header, a normal HTTP response such as 200 OK is returned and the connection remains on HTTP/1.1.
Hop-by-hop header
The Upgrade header is hop-by-hop, meaning each intermediary (proxy, load balancer, CDN) processes the header independently. Intermediaries are not required to forward the header. A reverse proxy sitting between client and server often terminates the upgrade request and establishes a separate connection to the backend.
Client-initiated upgrade
The client adds Upgrade and Connection to a standard HTTP request. Additional protocol-specific headers are included as needed. The server responds with 101 to accept or returns a regular response to decline.
The Upgrade header accepts a comma-separated list of protocol tokens. The order reflects client preference, with the most preferred protocol listed first.
Server-initiated upgrade
A server requiring a protocol change before fulfilling a request responds with 426 Upgrade Required. This informs the client the resource is available only over a different protocol. The response includes an Upgrade header listing the required protocol.
A common scenario: a server demands HTTPS
before serving a confidential resource, returning
426 with Upgrade: TLS/1.0 and a
Connection header containing the
Upgrade token. The client then initiates a TLS
connection.
There is no guarantee the server fulfills the request even after a successful upgrade.
WebSocket upgrade
The dominant real-world use of the protocol
upgrade mechanism is establishing
WebSocket connections over HTTP/1.1.
The client sends a GET request with
Upgrade: websocket along with the WebSocket
handshake headers.
Request
GET /chat HTTP/1.1
Host: www.example.re
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://example.re
Response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
After the server returns 101, subsequent data
flows as WebSocket frames rather than HTTP
messages. The Sec-WebSocket-Key and
Sec-WebSocket-Accept exchange confirms both sides
understand the WebSocket protocol and
prevents intermediary caches from replaying stale
upgrade responses.
HTTP/2, HTTP/3, and protocol negotiation
The protocol upgrade mechanism is specific to HTTP/1.1. HTTP/2 and HTTP/3 do not support the Upgrade header or the 101 status code.
The original HTTP/2 specification
included an upgrade path using the h2c token in
the Upgrade header for cleartext
HTTP/2 connections.
The current HTTP/2 specification deprecated this
mechanism because the approach was
never widely deployed. The h2c token must not be
sent by clients or selected by servers.
TLS ALPN
Modern HTTP version negotiation relies on TLS Application-Layer Protocol Negotiation (ALPN). During the TLS handshake, the client sends a list of supported protocol identifiers and the server selects one. This negotiation completes within the TLS handshake without adding extra round-trips.
Common ALPN protocol identifiers:
| Identifier | Protocol |
|---|---|
http/1.1 |
websocket-over-http/2-and-http/3- because-[[2">HTTP/2 lacks the Upgrade mechanism, WebSocket connections over HTTP/2 use the extended CONNECT method. The server advertises support through theSETTINGS_ENABLE_CONNECT_PROTOCOL setting, and the
client sends a CONNECT request with :protocol
set to websocket. The same approach extends to
HTTP/3.
WebSocket multiplexing The extended CONNECT method allows WebSocket traffic to share a single TCP connection (HTTP/2) or QUIC connection (HTTP/3) with regular HTTP streams, benefiting from multiplexing and flow control. TakeawayThe HTTP/1.1 protocol upgrade mechanism switches an active connection to a different protocol using the Upgrade and Connection headers. The server accepts with 101 Switching Protocols or demands an upgrade with 426 Upgrade Required. WebSocket is the primary protocol negotiated through this mechanism. HTTP/2 and HTTP/3 use TLS ALPN for version negotiation and the extended CONNECT method for WebSocket connections. See also
Last updated: March 6, 2026
|