HTTP 304 Not Modified : ce que cela signifie

Ce que signifie cette erreur et comment la reconnaître

• Un outil de développement de navigateur, un client API, un outil de monitoring ou un checker signale le statut 304 Not Modified.
• La réponse contient des en-têtes de cache ou de validation, mais aucun corps de ressource.
• Un navigateur peut afficher la page normalement, car il réutilise sa représentation mise en cache.
• Un client API ou un checker peut donner l’impression de recevoir une réponse vide s’il ne gère pas correctement le cache conditionnel.
• Le résultat peut concerner une seule URL ou ressource, et non l’ensemble du site.
• DNS et TLS peuvent toujours fonctionner, car le client a atteint un endpoint HTTP et reçu une réponse HTTP.

Causes principales, classées par probabilité

1. Le client a envoyé une requête conditionnelle. Des en-têtes de requête tels que If-None-Match ou If-Modified-Since demandaient si la représentation mise en cache était toujours à jour.
2. La ressource n’a pas changé. Le serveur ou un intermédiaire a fait correspondre le validateur fourni, tel qu’une valeur ETag ou Last-Modified, et a correctement renvoyé 304.
3. Un navigateur, un proxy ou un CDN a effectué une validation normale du cache. La réponse peut avoir été générée par un intermédiaire plutôt que par l’application d’origine.
4. Un client ou un outil de monitoring a présenté une réponse de cache normale comme une erreur. Certains outils sont configurés pour attendre un corps de réponse complet et peuvent ne pas réutiliser leur copie stockée.
5. La configuration des validateurs ou du cache est incohérente. Des résultats inattendus peuvent se produire lorsque les déploiements de l’application, les règles du proxy ou les en-têtes d’origine génèrent des validateurs obsolètes, contradictoires ou trop larges.

HTTP 304 n’est pas, à lui seul, une redirection, un échec d’authentification, une réponse de limitation de débit ou une panne du serveur. Ces situations doivent être confirmées à partir du statut réel, des en-têtes et des logs, plutôt que déduites de 304.

Comment corriger le problème

Pour les visiteurs

1. Laissez d’abord le navigateur gérer la réponse. Un navigateur normal doit utiliser sa copie mise en cache lorsqu’il reçoit 304. Si la page s’affiche correctement, aucune action n’est généralement nécessaire.
2. Vérifiez l’URL exacte. Confirmez le hostname, le chemin, la query string et le protocole. Des URL différentes peuvent avoir des représentations mises en cache distinctes.
3. Réessayez une fois si le contenu affiché est obsolète ou incomplet. Utilisez les commandes de rechargement habituelles du navigateur plutôt que d’actualiser la page de manière répétée.
4. Comparez avec un autre client uniquement si cela est utile. Si un navigateur affiche un contenu obsolète alors qu’un autre ne le fait pas, notez l’URL concernée, l’heure approximative et le comportement du client pour le propriétaire du site.
5. Contactez le propriétaire du site si la ressource ne peut pas être chargée. Signalez l’URL et l’horodatage, mais ne partagez pas de mots de passe, cookies, en-têtes d’autorisation ni autres données privées.

Pour les développeurs et propriétaires de sites

1. Capturez le contexte complet de la requête et de la réponse. Notez la méthode HTTP, l’URL complète avec les paramètres de requête pertinents, le statut, les validateurs de requête, les validateurs de réponse, Cache-Control, Vary ainsi que les en-têtes de proxy ou de CDN. Supprimez les identifiants et les données personnelles avant tout partage.
2. Confirmez que la requête est conditionnelle. Recherchez If-None-Match ou If-Modified-Since. Un 304 est normalement pertinent lorsque le client dispose d’une représentation mise en cache à valider.
3. Vérifiez la couche qui produit la réponse. Déterminez si le 304 provient du navigateur, d’un proxy local ou partagé, d’un CDN, d’un reverse proxy, du serveur web ou de l’application. Utilisez l’identifiant de requête et l’horodatage de ce composant lorsqu’ils sont disponibles.
4. Comparez les validateurs avec la ressource. Vérifiez que ETag ou Last-Modified représente correctement la représentation demandée et que la négociation de contenu est couverte par une politique Vary appropriée lorsque cela est pertinent.
5. Testez une requête inconditionnelle lorsque vous avez besoin du corps actuel. Utilisez un client de diagnostic autorisé ou omettez temporairement les en-têtes de requête conditionnelle dans un test contrôlé. Il s’agit d’une comparaison en lecture seule, mais respectez les contrôles d’accès habituels du service et évitez d’envoyer des en-têtes sensibles à des outils non fiables.
6. Examinez les changements récents du cache et des déploiements. Vérifiez les releases de l’application, la génération des assets, les règles du proxy ou du CDN, la compression et la négociation de contenu, le routage ainsi que le comportement d’invalidation du cache. Concentrez-vous sur les changements qui affectent la route concernée plutôt que de modifier immédiatement les paramètres globaux.
7. Appliquez la correction sûre la plus ciblée. Corrigez le validateur, la politique de cache ou la règle de l’intermédiaire uniquement après avoir identifié l’incohérence. Évitez de désactiver le cache globalement lorsqu’une seule route ou représentation est concernée.
8. Testez à nouveau le même chemin de requête. Testez à la fois une requête conditionnelle et une requête fraîche, puis confirmez que les routes et méthodes de requête associées renvoient toujours les statuts et représentations attendus.

Prévention et vérification du correctif

• Considérez 304 comme un résultat attendu de validation du cache dans le monitoring, sauf si le client ne peut pas utiliser sa représentation mise en cache.
• Testez les routes importantes avec des requêtes ordinaires et conditionnelles après les déploiements.
• Faites en sorte que le comportement de ETag, Last-Modified, Cache-Control et Vary soit intentionnel et documenté.
• Vérifiez que les validateurs du cache changent lorsque la représentation servie change, y compris pour les variantes pertinentes liées à la négociation de contenu.
• Surveillez les taux de statuts par route et par couche de cache afin de distinguer un schéma 304 inattendu du trafic normal des navigateurs.
• Dans la mesure du possible, gérez la configuration du proxy, du CDN, du serveur web et de l’application avec un contrôle de version.
• Conservez suffisamment longtemps les identifiants de requête et les horodatages assainis pour pouvoir relier un signalement à la couche qui a généré la réponse.

Questions fréquentes