425 Too Early

Uso

El error 425 Too Early está relacionado con el tiempo necesario para establecer una conexión HTTPS. Cuando hay una latencia considerable, el tiempo que TLS necesita para crear una conexión segura se alarga. Una optimización consiste en que el cliente envíe datos en una fase temprana del proceso, antes de que la conexión segura esté completamente establecida.

Si en la cadena interviene un intermediario, este debe incluir la cabecera de solicitud Early-Data: 1. Un intermediario no debe eliminar esta cabecera. Así se notifica al servidor que la solicitud se envió como datos anticipados y que el cliente entiende la respuesta 425 Too Early.

Solicitud

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

El iniciador original de una solicitud no necesita enviar esta cabecera. Al enviar datos de forma anticipada, el cliente da a entender que comprende las consecuencias y que gestionará adecuadamente la respuesta 425 Too Early.

En determinadas situaciones no conviene enviar datos anticipados, y el servidor devuelve este error como respuesta. El riesgo está en que la solicitud del cliente se reproduzca, lo que provocaría efectos secundarios que comprometen la seguridad.

Cuando un cliente recibe este código de estado, la solicitud se reintenta automáticamente, una vez completado el saludo (handshake) y establecida la conexión segura.

Impacto en SEO

Los motores de búsqueda como Google no indexarán una URL con un estado de respuesta 425. Las URL indexadas anteriormente que devuelvan este código de estado se eliminarán de los resultados de búsqueda.

Ejemplo

El cliente solicita un recurso y el servidor responde con 425 Too Early, indicándole que espere a que la conexión esté totalmente establecida antes de reintentar.

Solicitud

GET /tech-news HTTP/1.1
Host: example.com
Content-Type: application/xml
Content-Length: 225

<Message includes early data>

Respuesta

HTTP/1.1 425 Too Early

Cómo solucionarlo

Reintente la solicitud después de que el saludo TLS se haya completado por entero. El cliente espera a que la conexión segura termine de establecerse antes de reenviarla. La mayoría de los navegadores y bibliotecas HTTP gestionan este reintento de forma automática.

Evite enviar solicitudes no idempotentes (como POST, PUT o DELETE) en los datos anticipados de TLS 0-RTT. Solo las solicitudes GET idempotentes son seguras para los datos anticipados, porque su reproducción no genera efectos secundarios.

En el lado del servidor, en nginx la directiva ssl_early_data controla el comportamiento de 0-RTT. Establezca ssl_early_data off; para rechazar todos los datos anticipados y eliminar por completo esta respuesta. Cuando 0-RTT está habilitado, transmita la señal de datos anticipados al backend con proxy_set_header Early-Data $ssl_early_data; para que la aplicación decida en cada solicitud si acepta o rechaza los datos anticipados.

Las aplicaciones de backend que reciben la cabecera Early-Data: 1 rechazan con un 425 las solicitudes con efectos secundarios (cambios de cuenta, pagos, envíos de formularios). Los puntos de acceso de solo lectura, que son seguros, continúan con normalidad.

Los intermediarios que reenvían datos anticipados de un cliente deben conservar la cabecera Early-Data: 1. Eliminarla impide que el servidor de origen detecte el riesgo de reproducción.

Referencias de código

.NET

HttpStatusCode.TooEarly

Rust

http::StatusCode::TOO_EARLY

Rails

:too_early

http.StatusTooEarly

Symfony

Response::HTTP_TOO_EARLY

Python3.9+

http.HTTPStatus.TOO_EARLY

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_TOO_EARLY

Angular

@angular/common/http/HttpStatusCode.TooEarly