425 Too Early

Utilisation

L’erreur 425 Too Early est liée au temps nécessaire pour sécuriser une connexion HTTPS. En présence d’une latence importante, le temps requis par TLS pour établir une connexion sécurisée devient long. Une optimisation consiste pour le client à envoyer des données tôt dans le processus, avant que la connexion sécurisée ne soit entièrement établie.

Si un intermédiaire intervient dans la chaîne, il doit inclure l’en-tête de requête Early-Data: 1. Un intermédiaire ne doit pas supprimer cet en-tête. Celui-ci informe le serveur que la requête a été envoyée dans les données anticipées et que le client sait traiter la réponse 425 Too Early.

Requête

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

L’initiateur d’origine d’une requête n’a pas besoin d’envoyer cet en-tête. En envoyant des données de façon anticipée, le client sous-entend qu’il en comprend les conséquences et qu’il traite correctement la réponse 425 Too Early.

L’envoi de données anticipées est déconseillé dans certaines situations, et le serveur renvoie alors cette erreur en réponse. Le risque est que la requête du client soit rejouée, entraînant des effets de bord compromettant la sécurité.

Lorsqu’un client reçoit ce code de statut, la requête est réessayée automatiquement. Une fois la négociation terminée et la connexion sécurisée en place.

Impact SEO

Les moteurs de recherche comme Google n’indexeront pas une URL dont le statut de réponse est 425. Les URL précédemment indexées qui renvoient ce code de statut seront retirées des résultats de recherche.

Exemple

Le client demande une ressource et le serveur répond par 425 Too Early, invitant le client à attendre que la connexion soit entièrement établie avant de réessayer.

Requête

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

<Message includes early data>

Réponse

HTTP/1.1 425 Too Early

Comment corriger

Réessayez la requête une fois la négociation TLS entièrement terminée. Le client attend la fin de l’établissement de la connexion sécurisée avant de renvoyer la requête. La plupart des navigateurs et des bibliothèques HTTP gèrent ce nouvel essai automatiquement.

Évitez d’envoyer des requêtes non idempotentes (telles que POST, PUT ou DELETE) dans les données anticipées TLS 0-RTT. Seules les requêtes GET idempotentes sont sûres en données anticipées, car les rejouer n’a aucun effet de bord.

Côté serveur sous nginx, la directive ssl_early_data contrôle le comportement 0-RTT. Définissez ssl_early_data off; pour rejeter toutes les données anticipées et supprimer entièrement cette réponse. Lorsque 0-RTT est activé, transmettez le signal de données anticipées au backend avec proxy_set_header Early-Data $ssl_early_data; afin que l’application décide requête par requête d’accepter ou de rejeter les données anticipées.

Les applications backend qui reçoivent l’en-tête Early-Data: 1 rejettent les requêtes à effets de bord (modifications de compte, paiements, soumissions de formulaires) en répondant par 425. Les points de terminaison en lecture seule, sans risque, sont traités normalement.

Les intermédiaires qui relaient les données anticipées d’un client doivent préserver l’en-tête Early-Data: 1. Supprimer cet en-tête empêche le serveur d’origine de détecter le risque de rejeu.

Références de code

.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