425 Too Early

Verwendung

Der Fehler 425 Too Early hängt mit der Zeit zusammen, die zum Absichern einer HTTPS-Verbindung benötigt wird. Bei erheblicher Latenz wird die Zeit lang, die TLS zum Aufbau einer sicheren Verbindung braucht. Eine Optimierung besteht darin, dass ein Client Daten früh im Ablauf sendet, bevor die sichere Verbindung vollständig aufgebaut ist.

Ist ein Vermittler Teil der Kette, muss dieser den Anfrage-Header Early-Data: 1 hinzufügen. Ein Vermittler darf diesen Header nicht entfernen. Er teilt dem Server mit, dass die Anfrage als Early Data gesendet wurde und dass der Client die Antwort 425 Too Early versteht.

Anfrage

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

Der ursprüngliche Initiator einer Anfrage muss diesen Header nicht senden. Indem der Client Daten früh sendet, gibt er implizit zu erkennen, dass er die Konsequenzen kennt und die Antwort 425 Too Early angemessen behandelt.

In bestimmten Situationen ist das Senden von Early Data ungünstig, und der Server antwortet mit diesem Fehler. Das Risiko besteht darin, dass die Client-Anfrage wiedereingespielt wird und dadurch Seiteneffekte entstehen, die die Sicherheit gefährden.

Erhält ein Client diesen Statuscode, wird die Anfrage automatisch wiederholt – und zwar nachdem der Handshake abgeschlossen und die sichere Verbindung hergestellt ist.

SEO-Auswirkung

Suchmaschinen wie Google indexieren keine URL mit dem Antwortstatus 425. Zuvor indexierte URLs, die diesen Statuscode zurückgeben, werden aus den Suchergebnissen entfernt.

Beispiel

Der Client fordert eine Ressource an, und der Server antwortet mit 425 Too Early und weist den Client damit an, vor einem erneuten Versuch zu warten, bis die Verbindung vollständig aufgebaut ist.

Anfrage

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

<Message includes early data>

Antwort

HTTP/1.1 425 Too Early

Behebung

Wiederholen Sie die Anfrage, nachdem der TLS-Handshake vollständig abgeschlossen ist. Der Client wartet den Abschluss der sicheren Verbindung ab, bevor er erneut sendet. Die meisten Browser und HTTP-Bibliotheken führen diesen erneuten Versuch automatisch durch.

Vermeiden Sie es, nicht-idempotente Anfragen (etwa POST, PUT oder DELETE) in TLS-0-RTT-Early-Data zu senden. Nur idempotente GET-Anfragen sind für Early Data unbedenklich, da ihr Wiedereinspielen keine Seiteneffekte hat.

Serverseitig steuert in nginx die Direktive ssl_early_data das 0-RTT-Verhalten. Setzen Sie ssl_early_data off;, um sämtliche Early Data abzulehnen und diese Antwort vollständig auszuschließen. Ist 0-RTT aktiviert, reichen Sie das Early-Data-Signal mit proxy_set_header Early-Data $ssl_early_data; an das Backend weiter, damit die Anwendung pro Anfrage entscheidet, ob sie Early Data annimmt oder ablehnt.

Backend-Anwendungen, die den Header Early-Data: 1 erhalten, lehnen Anfragen mit Seiteneffekten (Kontoänderungen, Zahlungen, Formularübermittlungen) mit einer 425-Antwort ab. Unbedenkliche, rein lesende Endpunkte werden normal verarbeitet.

Vermittler, die Early Data eines Clients weiterleiten, müssen den Header Early-Data: 1 erhalten. Wird der Header entfernt, kann der Ursprungsserver das Replay-Risiko nicht erkennen.

Code-Referenzen

.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