HTTP 410 Gone : signification et solutions

Ce que signifie cette erreur et comment la reconnaître

• Un navigateur, un client API, un crawler, un outil de monitoring ou un outil de vérification de disponibilité signale 410 Gone.
• La réponse peut concerner une seule URL, un modèle de chemin, une méthode HTTP ou une version d’API plutôt que l’ensemble du site web.
• Le DNS peut toujours résoudre le nom et TLS peut toujours aboutir, car la requête a atteint un endpoint HTTP.
• Les en-têtes de réponse peuvent révéler le comportement du cache, une cible de redirection, le contexte d’authentification, des informations sur le proxy ou le CDN, ou encore le serveur qui a traité la requête.
• Répéter la requête renvoie généralement le même résultat lorsque la ressource a été intentionnellement supprimée.

Causes principales, classées par probabilité

Causes les plus probables

1. Suppression ou dépréciation intentionnelle de la ressource — Le propriétaire a supprimé définitivement une page, un fichier, un endpoint d’API ou une version, et a configuré l’ancienne adresse pour qu’elle renvoie 410.
2. Règle d’application ou de routage — L’application associe une route retirée, un enregistrement supprimé ou une version d’API non prise en charge à la réponse 410.
3. Réécriture du serveur web ou configuration de l’hôte virtuel — Une règle de routage, une modification lors d’un déploiement ou une configuration incorrecte du site renvoie 410 pour une URL qui devrait encore fonctionner.
4. Comportement du reverse proxy ou du CDN — Un intermédiaire peut avoir mis la réponse en cache ou l’avoir générée en fonction de sa configuration de routage, de cache ou d’edge.
5. Incompatibilité de la requête — L’URL peut être valide pour une méthode ou une forme de chemin, mais supprimée ou non prise en charge pour la méthode utilisée.
6. Logique de sécurité ou de traitement des requêtes personnalisée — Un WAF, une gateway ou une politique applicative peut utiliser volontairement 410, même si les problèmes d’authentification, d’autorisation et de limitation de débit utilisent souvent d’autres codes d’état.

Le code d’état seul ne permet pas d’identifier le composant qui a produit la réponse. Les en-têtes de réponse, les horodatages et les journaux sont nécessaires pour distinguer une suppression prévue d’une règle accidentelle ou d’une réponse obsolète provenant d’un intermédiaire.

Comment corriger le problème

Si vous consultez le site

1. Vérifiez attentivement l’adresse, notamment le hostname, le chemin, l’orthographe, la casse et tout segment de version.
2. Réessayez une fois l’URL exacte sans l’actualiser de manière répétée. Si la page nécessite un compte, connectez-vous via le processus habituel du site, puis réessayez.
3. Si vous êtes arrivé sur cette URL depuis un ancien favori, un résultat de recherche ou un lien externe, consultez la navigation actuelle du site ou recherchez un remplacement annoncé. Ne supposez pas qu’un 410 possède une destination équivalente.
4. Si la réponse persiste alors que la ressource devrait toujours exister, envoyez au propriétaire du site l’URL, l’heure de la requête, la méthode HTTP et le résultat 410 affiché. N’envoyez pas de mots de passe, cookies ou jetons d’accès.

Si vous possédez ou développez le site

1. Reproduisez la requête exacte. Notez l’URL, la méthode HTTP, l’hôte, les paramètres de requête, le statut, les en-têtes de réponse et indiquez si la requête était authentifiée. Comparez la requête en échec avec une route ou une méthode associée connue pour fonctionner.
2. Déterminez si le 410 est intentionnel. Vérifiez si la page, le fichier, l’enregistrement ou la version d’API a été délibérément supprimé. Si c’est le cas, documentez la suppression et conservez la réponse, sauf si un remplacement approprié est nécessaire.
3. Identifiez la couche qui produit la réponse. Vérifiez si les en-têtes et le chemin de requête indiquent que l’application, le serveur web, le reverse proxy, le CDN ou le WAF a généré la réponse. Examinez chaque couche du chemin de requête plutôt que de toutes les modifier en même temps.
4. Examinez les journaux correspondants. Recherchez dans les journaux d’accès, de l’application, du proxy, du CDN ou de sécurité concernés en utilisant l’horodatage, la route et l’identifiant de requête. Recherchez une règle de suppression, un enregistrement supprimé, une réécriture, une modification de déploiement ou une réponse mise en cache.
5. Vérifiez les modifications récentes et l’état du cache. Comparez la configuration du routage, des versions d’API, de l’authentification, des réécritures et du cache edge avec le dernier déploiement connu comme fonctionnel. Si un intermédiaire a mis en cache une réponse incorrecte, suivez sa procédure documentée et autorisée d’invalidation du cache au lieu de désactiver largement la mise en cache.
6. Appliquez la correction autorisée la plus ciblée. Restaurez la route ou supprimez la règle erronée uniquement lorsque la ressource doit être disponible. Si un remplacement équivalent existe, configurez et testez une redirection volontaire ; ne redirigez pas des URL sans rapport ou inexistantes dans le seul but de masquer le 410.
7. Testez à nouveau la même requête. Vérifiez le statut, les en-têtes et le corps de la réponse depuis le client concerné et, le cas échéant, depuis le réseau ou l’emplacement edge affecté. Confirmez que les routes intentionnellement supprimées se comportent comme prévu dans la documentation et que les routes associées conservent leurs statuts prévus.
8. Examinez le monitoring et la documentation. Mettez à jour l’inventaire des routes, les avis de dépréciation d’API, les redirections et les tests afin qu’une prochaine version ne supprime pas accidentellement une ressource active.

Prévention et vérification du correctif

• Tenez à jour un inventaire des routes web, fichiers et versions d’API importantes, y compris leur comportement prévu lors d’une suppression.
• Traitez les suppressions intentionnelles comme des modifications de release : documentez-les, testez-les et identifiez toute URL de remplacement approuvée.
• Gérez la configuration de l’application, du serveur web, du proxy, du CDN et du WAF avec un contrôle de version, et examinez les changements de routage avant chaque déploiement.
• Testez les URL et méthodes d’API importantes après les releases, migrations et dépréciations.
• Surveillez les taux de statuts HTTP par route, méthode et déploiement afin de distinguer les réponses 410 inattendues des suppressions planifiées.
• Conservez les journaux d’accès et de l’application suffisamment longtemps pour relier une réponse à la couche responsable.
• Définissez des procédures d’invalidation du cache et de rollback pour les réponses accidentelles provenant de l’edge ou d’un proxy.

Questions fréquentes