HTTP 408 Request Timeout : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un outil d’upload, un synthetic monitor ou un health checker reçoit 408 Request Timeout.
• L’erreur peut ne concerner qu’une URL, une méthode HTTP, un client, un upload ou un chemin réseau, et non l’ensemble du site.
• Une requête qui envoie un corps, comme un upload ou l’envoi d’un formulaire, peut échouer après que la connexion est restée ouverte sans parvenir à son terme.
• Les en-têtes de réponse peuvent indiquer si la réponse a été générée par un proxy, un CDN, un load balancer, un WAF ou le serveur d’origine.
• La résolution DNS et la négociation TLS peuvent réussir même si la requête HTTP qui suit reçoit un 408.
• Les logs peuvent faire apparaître une requête incomplète, une connexion inactive, un délai d’expiration lors de la lecture de la requête ou un délai généré avant que la requête n’atteigne l’application.

Causes principales, classées par probabilité

1. Le client n’a pas terminé l’envoi de la requête. Un upload lent, une connexion bloquée, une requête interrompue dans le navigateur ou un corps de requête incomplet peuvent dépasser le délai d’attente du serveur.
2. Une connexion persistante inactive a expiré. Un serveur ou un intermédiaire peut fermer une connexion keep-alive lorsque la requête suivante n’arrive pas ou ne s’achève pas pendant la période d’inactivité configurée.
3. Un proxy, un CDN, un load balancer ou un WAF a atteint son délai d’expiration en premier. Les différentes couches peuvent appliquer des limites distinctes pour les en-têtes de requête, le corps de la requête, l’inactivité de la connexion ou la durée totale.
4. Une instabilité réseau a retardé la transmission de la requête. Des pertes de paquets, une connexion interrompue ou un chemin réseau défaillant peuvent empêcher le point de terminaison de recevoir la requête complète.
5. Les détails de la requête déclenchent une règle propre à une couche. Un corps volumineux, des en-têtes inhabituels, un mode de transfert non pris en charge ou une règle spécifique à la méthode peuvent amener un intermédiaire à cesser d’attendre ou à rejeter le chemin de la requête.
6. La réponse a été mal classée ou générée par une infrastructure personnalisée. Certains systèmes utilisent 408 pour une condition d’expiration qui ne correspond pas au scénario standard d’une requête client. Il faut donc vérifier le composant à l’origine de la réponse et ses logs.

Comment corriger le problème

Si vous consultez le site

1. Réessayez une fois l’URL exacte après avoir vérifié que l’adresse est correcte.
2. Si vous étiez en train d’envoyer un fichier ou de soumettre un formulaire, vérifiez que la connexion est restée stable et que l’opération peut être reprise en toute sécurité.
3. Si la requête nécessite un compte, connectez-vous via le parcours normal du site et réessayez ; ne renvoyez pas plusieurs fois un formulaire ou une demande de paiement sans vérifier que la première requête a bien été traitée.
4. Si l’erreur persiste, notez l’URL, la méthode HTTP si elle est connue, l’heure approximative, le type de réseau et la réponse 408 visible. Envoyez ces informations au propriétaire du site sans communiquer de mots de passe, cookies, données de paiement ou clés API.

Si vous développez ou exploitez le service

1. Capturez la requête exacte. Notez la méthode, le chemin de l’URL, les caractéristiques de taille de la requête, les en-têtes pertinents, la présence éventuelle d’un corps, le statut de réponse, les en-têtes de réponse et l’horodatage. Masquez les identifiants, cookies, valeurs d’autorisation et données personnelles.
2. Reproduisez les mêmes conditions. Comparez une requête normale avec la méthode, le client, la taille de l’upload, le type de connexion et le comportement du corps de la requête en échec. La réussite d’un simple GET n’exclut pas un délai d’expiration pour un POST, un upload, une requête en streaming ou une autre méthode.
3. Localisez la couche qui a généré la réponse. Examinez les en-têtes de réponse ainsi que les identifiants de requête ou de trace, puis faites correspondre l’horodatage dans les logs du CDN, du WAF, du load balancer, du reverse proxy, du serveur web et de l’application. La première couche qui enregistre le délai d’expiration constitue généralement le meilleur point de départ.
4. Examinez les paramètres de lecture de la requête et de délai d’inactivité. Vérifiez les paramètres pertinents du serveur et des intermédiaires pour les en-têtes incomplets, les corps de requête lents, les connexions keep-alive et la durée totale de la requête. Comparez-les au comportement attendu de l’application concernant les uploads et les clients.
5. Vérifiez le chemin réseau et le comportement du client. Recherchez les réinitialisations de connexion, les pertes de paquets, les uploads bloqués, les changements de proxy ou un client qui ouvre une connexion sans terminer l’envoi de la requête.
6. Comparez les changements récents. Examinez les déploiements et les modifications du routage, des paramètres du proxy/CDN, des règles WAF, des limites de taille des requêtes, du middleware d’authentification et de la gestion des connexions. Considérez l’authentification ou l’autorisation comme une piste secondaire, sauf si les logs montrent que la requête a atteint cette logique.
7. Appliquez la correction autorisée la plus ciblée. Modifiez uniquement le délai d’expiration ou la règle de traitement des requêtes responsable, ou corrigez le comportement du client. Ne désactivez pas largement les contrôles de sécurité et n’augmentez pas tous les délais sans comprendre les implications en matière de capacité et d’abus.
8. Retestez et surveillez. Répétez la requête d’origine en toute sécurité, vérifiez que le statut attendu est renvoyé et contrôlez les routes et méthodes associées. Pour les requêtes non idempotentes, utilisez un cas de test approuvé ou confirmez le résultat de l’opération avant de réessayer.

Prévention et vérification du correctif

• Surveillez les taux de statuts HTTP par route, méthode, type de client et déploiement afin qu’un délai d’expiration propre à une requête ne soit pas masqué dans une métrique agrégée.
• Documentez et, lorsque cela est pris en charge, versionnez les paramètres de délai d’expiration du CDN, du WAF, du load balancer, du reverse proxy, du serveur web et de l’application.
• Testez les uploads lents, les requêtes incomplètes, le comportement keep-alive et les méthodes API importantes dans un environnement contrôlé.
• Configurez délibérément les délais d’expiration des requêtes et des connexions, en équilibrant le comportement légitime des clients avec la consommation de ressources et le risque d’abus.
• Conservez des horodatages synchronisés ainsi que les identifiants de requête ou de trace entre les différentes couches réseau.
• Définissez explicitement le comportement de retry des clients, en particulier pour les requêtes non idempotentes comme l’envoi de formulaires, les commandes ou les paiements.
• Conservez suffisamment de logs et de métriques assainis pour relier un 408 au composant qui l’a émis.

Questions fréquentes