426 Upgrade Required

Uso

Cuando se recibe el código de estado 426 Upgrade Required, la respuesta incluye un campo de cabecera de respuesta Upgrade que indica el protocolo o los protocolos requeridos.

Este mensaje está relacionado con el mensaje 101 Switching Protocols, que se envía en respuesta a una solicitud de actualización de protocolo realizada por el cliente mediante la cabecera Upgrade.

Impacto en SEO

Los motores de búsqueda como Google no indexan una URL cuya respuesta tenga el estado 426. Las URL indexadas previamente que devuelvan este código de estado se eliminarán de los resultados de búsqueda.

Ejemplo

El cliente solicita un recurso mediante HTTP en claro y el servidor responde con 426 Upgrade Required porque TLS es obligatorio. El cliente cambia a HTTPS y la solicitud se completa correctamente.

HTTP/2 y HTTP/3

HTTP/2 y HTTP/3 se negocian mediante ALPN durante el saludo TLS, no a través de la cabecera Upgrade. El mecanismo de actualización a HTTP/2 en claro (h2c) se eliminó de la especificación. La cabecera Upgrade se aplica a cambios de protocolo como TLS y WebSocket.

Solicitud inicial

GET /tech-news HTTP/1.1
Host: example.com

Respuesta inicial

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.2
Connection: upgrade
Content-Type: text/html
Content-Length: 140

<html>
  <head>
    <title>TLS Required</title>
  </head>
  <body>
   <p>This service requires TLS.</p>
  </body>
</html>

Solicitud posterior mediante HTTPS

GET /tech-news HTTP/1.1
Host: example.com

Respuesta

HTTP/1.1 200 OK
Content-Type: text/html

Cómo solucionarlo

Lea la cabecera Upgrade de la respuesta para identificar el protocolo requerido. El servidor enumera uno o varios protocolos aceptables, como TLS/1.2, HTTP/2, HTTP/3 o websocket.

Para las actualizaciones de versión de protocolo, cambie el cliente al protocolo indicado y vuelva a enviar la solicitud. HTTP/2 y HTTP/3 usan ALPN durante el saludo TLS en lugar de la cabecera Upgrade. Para otros protocolos como WebSocket, incluya Connection: upgrade y la cabecera Upgrade correspondiente. El servidor responde con 101 Switching Protocols y la conexión continúa bajo el nuevo protocolo.

Para las conexiones WebSocket a través de nginx, configure el proxy para que reenvíe las cabeceras upgrade:

Sin estas directivas, nginx usa HTTP/1.0 de forma predeterminada en las conexiones con el servidor de origen y elimina las cabeceras upgrade, lo que produce un 426 en cada intento de saludo WebSocket.

Cuando un servidor impone HTTPS, cambie el esquema de la URL de la solicitud de http:// a https://. Verifique que TLS 1.2 o TLS 1.3 esté habilitado en el cliente o en el entorno de ejecución. Las versiones antiguas de TLS suelen rechazarse.

Actualice las bibliotecas cliente y los SDK cuando no admitan el protocolo requerido. Las bibliotecas HTTP obsoletas usan HTTP/1.1 de forma predeterminada y carecen de capacidad de negociación de HTTP/2 o HTTP/3.

Elimine las cabeceras Upgrade innecesarias de las solicitudes que no pretenden cambiar de protocolo. Algunos proxies interpretan una cabecera Upgrade sobrante como un intento de negociación de protocolo y devuelven 426.

Referencias de código

.NET

HttpStatusCode.UpgradeRequired

Rust

http::StatusCode::UPGRADE_REQUIRED

Rails

:upgrade_required

http.StatusUpgradeRequired

Symfony

Response::HTTP_UPGRADE_REQUIRED

Python3.5+

http.HTTPStatus.UPGRADE_REQUIRED

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_UPGRADE_REQUIRED

Angular

@angular/common/http/HttpStatusCode.UpgradeRequired