Skip to content

426 Upgrade Required

The server refuses the request on the current protocol and names the protocol the client must switch to.

Status

HTTP/1.1 426 Upgrade Required

Details

  • Category: 4xx
  • Status: Standard. Registered with IANA and defined by a current standards-track RFC.
  • Specification: RFC 9110 §15.5.22, RFC 9110 §7.8: Upgrade header field
  • Cacheable: Only with explicit cache headers
  • Response body: Allowed
  • Retry: Retry only after changing the request

426 is a refusal with instructions. The server will not serve this resource over the protocol in use, and the Upgrade header names what it wants instead. The classic case is a WebSocket endpoint answering a plain GET, telling the client to upgrade rather than poll.

It can also be used to force a newer version of a protocol, for example refusing an obsolete TLS version at the application layer.

Headers

  • Upgrade: Required. Names the protocol the client must use, e.g. websocket or HTTP/2.0.
  • Connection: Must be Upgrade.

Common causes

  • A plain HTTP GET against a WebSocket-only endpoint.
  • A missing Sec-WebSocket-Key or version header on an upgrade attempt.
  • A server requiring a newer protocol version than the client offered.

How to fix it

As the client

  • Send the upgrade handshake with the headers the server named.
  • Verify that every proxy in the path forwards Upgrade and Connection, since stripping them turns a successful handshake into a 426 loop.

As the server

  • Always name the required protocol in Upgrade. A 426 without it tells the client nothing.
  • Return a short explanatory body for developers hitting the endpoint from a browser.

Examples

Hitting a WebSocket endpoint with plain HTTP

HTTP request

GET /socket HTTP/1.1
Host: realtime.example.com

HTTP response

HTTP/1.1 426 Upgrade Required
Upgrade: websocket
Connection: Upgrade

Specifications

See also