HTTP 505 HTTP Version Not Supported : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un système de monitoring ou un outil en ligne de commande reçoit 505 HTTP Version Not Supported.
• La réponse peut contenir un message indiquant que la version HTTP demandée n’est pas prise en charge.
• Le DNS peut fonctionner correctement et TLS peut s’établir correctement, car le client a ensuite reçu une réponse HTTP.
• L’erreur peut se produire uniquement avec un client, un chemin de négociation de protocole, une URL, une méthode HTTP ou un intermédiaire donné.
• Les en-têtes de réponse peuvent révéler si la réponse provient d’un proxy, d’un CDN, d’un load balancer ou d’un serveur d’origine, et peuvent fournir des informations sur la mise en cache ou la connexion.

Causes principales, classées par probabilité

1. Version du protocole HTTP non prise en charge : L’endpoint ne prend pas en charge la version majeure du protocole HTTP utilisée dans la requête. Il s’agit de la cause caractéristique du statut 505.
2. Incompatibilité de protocole entre un intermédiaire et son upstream : Un reverse proxy, un CDN, un load balancer ou une gateway peut utiliser une version de protocole que le serveur suivant n’accepte pas, ou renvoyer sa propre réponse 505.
3. Configuration du protocole HTTP incorrecte ou incomplète : Une modification récente du serveur, du proxy ou de l’application peut avoir activé ou exigé une version de protocole qui n’est pas prise en charge sur l’ensemble du chemin de la requête.
4. Négociation ou comportement de requête spécifique au client : Un client ou un outil de monitoring peut sélectionner un protocole HTTP différent de celui des navigateurs ou d’autres clients, révélant ainsi un problème de compatibilité.
5. Réponse inattendue provenant d’une couche autre que l’origine : Le statut peut être produit par une gateway ou un intermédiaire de sécurité plutôt que par l’application qui gère l’URL. Les en-têtes et les logs sont nécessaires pour distinguer ces deux cas.

L’authentification, les limites de débit, le DNS et TLS peuvent affecter une requête, mais n’expliquent pas à eux seuls une réponse HTTP 505. Traitez-les comme des pistes d’investigation distinctes, sauf si les en-têtes de réponse ou les logs établissent un lien avec l’échec de version du protocole.

Comment corriger le problème

Pour les visiteurs et les utilisateurs d’API

1. Réessayez une fois avec l’URL exacte et vérifiez que le client est à jour et configuré pour effectuer une requête HTTP normale.
2. Si le problème se produit dans un client API ou un outil de monitoring, comparez le résultat avec un autre client pris en charge. Notez si l’échec est spécifique au client.
3. Notez l’URL, la méthode HTTP, l’heure approximative, le statut de la réponse et ses en-têtes. N’incluez pas de mots de passe, cookies, tokens d’autorisation ni autres secrets.
4. Si l’erreur persiste, transmettez ces informations anonymisées au propriétaire du site ou de l’API. Un visiteur ne peut généralement pas corriger un problème de compatibilité de protocole côté serveur.

Pour les développeurs et les propriétaires de sites

1. Capturez la requête exacte. Notez le hostname, le chemin, la méthode, le protocole de la requête, le client, l’horodatage et le statut final. Confirmez que la réponse est bien 505, et non une redirection ou un statut affiché par un client après un autre échec.
2. Vérifiez la négociation du protocole. Déterminez la version HTTP que le client a utilisée ou tenté d’utiliser, ainsi que les versions prises en charge par l’endpoint, le proxy, le load balancer ou le CDN. Pour les connexions chiffrées, examinez le protocole applicatif négocié lorsque vos outils l’exposent.
3. Identifiez la couche qui a produit la réponse. Utilisez les en-têtes de réponse, les signatures du serveur lorsqu’elles sont disponibles, les identifiants de requête et les access logs pour déterminer si le 505 provient du CDN, du WAF, de la gateway, du reverse proxy, du serveur web ou de l’application.
4. Corrélez les logs. Recherchez dans la couche identifiée et dans la couche upstream le même horodatage, la même route, la même méthode, le même client et le même request ID. L’absence de log côté origine peut indiquer qu’un intermédiaire a rejeté la requête avant de la transmettre.
5. Examinez les modifications récentes du protocole. Vérifiez les déploiements et changements de configuration récents affectant la prise en charge des versions HTTP, les connexions proxy-vers-origine, les listeners du load balancer, le routage de la gateway et la configuration du client ou du monitoring.
6. Appliquez la correction autorisée la plus ciblée. Alignez le client, l’intermédiaire et l’origine concernés sur une version de protocole prise en charge par l’ensemble du chemin de la requête. Ne désactivez pas la validation TLS, l’authentification ni les contrôles de sécurité comme solution de contournement.
7. Retestez la même requête. Vérifiez l’URL et la méthode d’origine, puis testez des routes et des chemins de protocole représentatifs. Confirmez que la correction n’a pas modifié d’autres codes de statut ni le comportement du routage.
8. Utilisez un déploiement contrôlé pour les infrastructures partagées. Si le paramètre concerné dessert de nombreux sites ou routes, testez-le dans un environnement de staging approuvé ou dans le cadre d’une modification à portée limitée avant de l’appliquer globalement. Suivez les procédures de modification et de rollback de l’environnement.

Prévention et vérification du correctif

• Documentez les versions HTTP prises en charge par les clients, les gateways, les proxies, les load balancers et les serveurs d’origine pour chaque chemin de requête.
• Après toute modification du protocole ou de l’infrastructure, testez les routes importantes des navigateurs et les méthodes API à travers le chemin réel, ou équivalent à la production, des proxies et du CDN.
• Surveillez les codes de statut par route, type de client, protocole et déploiement afin de détecter les réponses 505 spécifiques à un client.
• Gérez la configuration des proxies, load balancers, serveurs web et applications dans un système de contrôle de version avec une procédure de rollback testée.
• Conservez les logs d’accès et de gateway corrélés suffisamment longtemps pour identifier la couche qui a généré une réponse inattendue.
• Maintenez les outils de monitoring et les clients API à jour, et validez leurs paramètres de protocole lors de leur intégration ou de toute modification de configuration.

Questions fréquentes