HTTP 426 Upgrade Required – Free, Online, Private

What HTTP 426 means

426 says the server is unwilling to process the request using the current protocol, and the Upgrade header names what it is willing to use. The client may open a new attempt with that protocol. It is the demand that pairs with 101, which is the successful switch. You might see it when a server requires TLS or a newer HTTP version and is configured to say so rather than fail the handshake earlier.

426 Upgrade Required belongs to the 4xx client error class. Clients that only look at the class will group it with its neighbors. Clients that care about the exact code should use the narrower rule on this page, because the class is only the first digit.

When you see HTTP 426

When you see HTTP 426 Upgrade Required, stop on that exact status line. 426 Upgrade Required means the server refuses the current protocol and names the one it wants. The trace that usually produces it: A server required HTTP/2 or WebSocket and received a plain request it will not answer. The 4xx client error class only tells you the first digit. A neighbor in that class is a different fault, and the fix on this page does not transfer to it.

Return 426 when you will not serve this request on this protocol and you want the client to move. Send Upgrade. If you can serve the request, do so. Do not use 426 to advertise optional features. An optional upgrade is an Upgrade header on a normal 200, which the client may ignore.

How to fix HTTP 426

To fix HTTP 426, change the condition that made the server choose Upgrade Required. If you support the named protocol, retry with it. If you do not, stop. Do not loop on the old protocol. Once, with the upgraded protocol. Not with the same protocol. If the log line is a different code, leave this page. The mix-up people make with 426 is this one: 101 means the switch already happened on this connection. 426 means it has not, and this request was refused. 505 means the HTTP version is not supported, which is related but specific to the version.

• Upgrade named a protocol the client does not implement, so the client stopped.
• A client retried on the same protocol and received 426 again.
• A load balancer emitted 426 while the origin would have answered, because the protocols differed.

An access log that only stores 426 is not enough to tell these apart. Keep the method, the path, and a request id. Do not keep the Authorization header or a request body that might be a token. The status explains the outcome. It is not a place to echo secrets back to the client either.

Example response

HTTP 426 Upgrade RequiredHTTP/1.1 426 Upgrade Required
Upgrade: h2c
Connection: Upgrade

Upgrade lists h2c in this example. Connection: Upgrade keeps the header hop-by-hop. The client that understands h2c starts that protocol. A client that does not is finished. Choose a protocol your clients actually have. A 426 nobody can follow is a 403 with extra steps.

What the client should do

If you support the named protocol, retry with it. If you do not, stop. Do not loop on the old protocol.

Do not cache 426 as the resource representation. It is a property of how you connected.

Once, with the upgraded protocol. Not with the same protocol.

Codes people confuse with HTTP 426

101 means the switch already happened on this connection. 426 means it has not, and this request was refused. 505 means the HTTP version is not supported, which is related but specific to the version.