408 Request Timeout

Verwendung

Wenn ein 408 Request Timeout-Fehler eintrifft, hat der Client eine Anfrage gestartet, aus irgendeinem Grund aber nicht die vollständige Nutzlast übertragen. Das tritt auf, wenn eine Internetverbindung langsam ist oder abgebrochen wurde. Die Antwort enthält den Connection-Header, der angibt, dass die Verbindung geschlossen wurde.

Nach dem Empfang des Headers Connection: close versucht der Client die Anfrage erneut.

Hinweis

408 Request Timeout bedeutet, dass der Client die Anfrage zu langsam an den Server gesendet hat. 504 Gateway Timeout bedeutet, dass bei einem Proxy oder Gateway beim Warten auf die Antwort des Backend-Servers eine Zeitüberschreitung aufgetreten ist. 408 ist eine Zeitüberschreitung zwischen Client und Server, während 504 eine Zeitüberschreitung zwischen Servern ist. 408 gehört zu den wenigen 4xx-Codes, die einen automatischen Wiederholungsversuch rechtfertigen, da die Ursache typischerweise vorübergehend ist.

SEO-Auswirkung

Suchmaschinen wie Google indexieren keine URL, die einen 408-Status zurückgibt. Zuvor indexierte URLs, die diesen Statuscode zurückgeben, werden aus den Suchergebnissen entfernt.

Beispiel

Der Client beginnt, eine 10K große PDF-Datei an den Server zu senden, doch die Verbindung leidet unter zeitweiligen Konnektivitätsproblemen, und der Server kommt zu dem Schluss, dass die Übertragung zu langsam ist. Der Server bricht die Anfrage ab und schließt die Verbindung. Sobald sich die Verbindung stabilisiert hat, überträgt der Client die Datei erfolgreich erneut.

Erste Anfrage

PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
Content-Length: 10000

Erste Antwort

HTTP/1.1 408 Request Timeout
Connection: Close
Content-Type: text/html
Content-Length: 198

<html>
  <head>
    <title>Connection Close</title>
  </head>
  <body>
    <p>The transmission was not received quickly
    enough. Check connectivity and try again.</p>
  </body>
</html>

Nächste Anfrage

PUT /docs HTTP/1.1
Host: example.com
Content-Type: application/pdf
Content-Length: 10000

<File transfer successful for PDF file>

Abschließende Antwort

HTTP/1.1 200 OK

Behebung

Ein 408 Request Timeout bedeutet, dass der Server die Verbindung geschlossen hat, weil der Client die Anfrage nicht rechtzeitig abgeschlossen hat.

Prüfen Sie Netzwerkkonnektivität und Latenz. Eine instabile oder langsame Verbindung verzögert die Übertragung der Anfrage. Führen Sie ping und traceroute zum Server aus, um Paketverluste oder Hops mit hoher Latenz zu identifizieren. Stellen Sie sicher, dass die Verbindung stabil ist, bevor Sie es erneut versuchen.

Verringern Sie die Größe der Nutzlast oder teilen Sie große Uploads auf. Das Senden einer großen Datei über eine langsame Verbindung übersteigt die Geduld des Servers. Komprimieren Sie die Nutzlast, verwenden Sie Transfer-Encoding mit Chunks, oder zerlegen Sie den Upload mithilfe von Multipart-Upload-APIs in kleinere Teile.

Erhöhen Sie die clientseitigen Timeout-Einstellungen. Die HTTP-Client-Bibliothek oder der Browser erzwingt ein eigenes Timeout. Setzen Sie die Werte für Verbindungs- und Lese-Timeout herauf, um langsamere Übertragungen zu ermöglichen. In curl verwenden Sie —connect-timeout und —max-time. In Python requests setzen Sie timeout=(connect, read).

Überprüfen Sie die Timeout-Konfiguration des Servers. Passen Sie die Timeout-Direktiven je nach Webserver an:

nginx:

client_header_timeout 60s;
client_body_timeout 60s;
keepalive_timeout 75s;
send_timeout 60s;

Apache:

Timeout 60
KeepAliveTimeout 5
RequestReadTimeout header=20-40 body=20

Die Direktive RequestReadTimeout (mod_reqtimeout) steuert die Lese-Timeouts für Header und Body getrennt. Erhöhen Sie diese Werte, wenn Clients berechtigterweise mehr Zeit benötigen.

Passen Sie die Keep-Alive-Einstellungen an. Ein zu niedriges keepalive_timeout schließt inaktive Verbindungen, bevor der Client die nächste Anfrage in einer persistenten Verbindung sendet. In nginx beträgt das voreingestellte keepalive_timeout 75 Sekunden. Erhöhen Sie den Wert für APIs, die Clients mit schubweisen Anfragemustern bedienen. In Apache erhöhen Sie KeepAliveTimeout (Standard 5 Sekunden) und überprüfen Sie, ob MaxKeepAliveRequests genügend Anfragen pro Verbindung zulässt.

Prüfen Sie die Timeouts von Reverse-Proxys und Load-Balancern. Wenn ein Reverse-Proxy (nginx, HAProxy, AWS ELB) dem Anwendungsserver vorgeschaltet ist, erzwingt jede Schicht ihr eigenes Timeout. Der Proxy schließt die Verbindung zuerst, wenn sein Timeout kürzer ist als das des Backends. Im Reverse-Proxy-Modus von nginx:

proxy_connect_timeout 60s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;

AWS ALB hat ein voreingestelltes Idle-Timeout von 60 Sekunden, das in den Attributen des Load-Balancers konfigurierbar ist.

Wiederholen Sie die Anfrage. Ein 408 ist oft vorübergehend. Bauen Sie die Verbindung neu auf und senden Sie die vollständige Anfrage erneut. Implementieren Sie für programmatische Clients eine automatische Wiederholungslogik mit exponentiellem Backoff. Der Retry-After-Header gibt, sofern vorhanden, an, wie lange vor einem erneuten Versuch gewartet werden soll.

Sehen Sie die Fehlerprotokolle des Servers durch. nginx protokolliert Timeout-Ereignisse im Fehlerprotokoll. Apache protokolliert Verstöße gegen mod_reqtimeout. Prüfen Sie /var/log/nginx/error.log oder /var/log/apache2/error.log auf Einträge, die zum Zeitstempel der Anfrage passen, um festzustellen, ob das Lesen des Headers oder des Bodys zeitlich überschritten wurde.

Code-Referenzen

.NET

HttpStatusCode.RequestTimeout

Rust

http::StatusCode::REQUEST_TIMEOUT

Rails

:request_timeout

http.StatusRequestTimeout

Symfony

Response::HTTP_REQUEST_TIMEOUT

Python3.5+

http.HTTPStatus.REQUEST_TIMEOUT

Java

java.net.HttpURLConnection.HTTP_CLIENT_TIMEOUT

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_REQUEST_TIMEOUT

Angular

@angular/common/http/HttpStatusCode.RequestTimeout