Distinguer le cache en périphérie des images publiques des limites de l’API

Dans un journal ou un catalogue contenant des images, chaque changement de date ou de page déclenche des requêtes vers l’API de contenu et vers les images. Nous décrivons un cas où les images ont cessé de se charger lors de consultations répétées, sans révéler les URL opérationnelles, les routes internes ni les valeurs de limite.

Reproduire la consultation successive à partir d’une image

Récupérez plusieurs fois la même image publique et comparez hash du corps, statut et cache. Chargez ensuite texte et images par navigation normale et vérifiez quelles requêtes consomment le quota. Un HIT ne suffit pas : vérifiez contenu correct et protection de l’API.

Cloudflare Cache API：Lecture conditionnelle et cache par emplacement

Le contenu et les images partageaient la même limite

Dans ce cas, les requêtes vers une API dynamique et les requêtes GET des images publiques étaient comptabilisées par la même règle de limitation du WAF. Même un changement de page ordinaire pouvait déclencher plusieurs requêtes à la fois : le contenu était chargé, mais les images pouvaient être limitées.

Ajouter un cache en périphérie pour les images n’aide pas les requêtes que le WAF bloque avant qu’elles ne l’atteignent. Nous avons modifié séparément la charge à l’origine et les types de requêtes comptabilisées dans la même limite. Les limites existantes de l’application et les quotas du processus de génération restent en place pour leurs objectifs respectifs.

Ne réutiliser que des images publiques partageables

Les images concernées ici sont immuables : un même asset ID public renvoie toujours le même contenu. Nous validons le format de l’asset ID, la frontière de la requête et la configuration du Service Binding avant de consulter une entrée de cache indexée par le même host et le même asset ID. Un cache déjà rempli ne permet pas d’omettre ces contrôles d’entrée.

Les chaînes de requête sans effet sur le contenu et les en-têtes de la requête de l’utilisateur final ne créent pas de variantes de cache pour une même image. Ce choix n’est possible que parce qu’il s’agit d’images publiques et immuables. Il ne peut pas être appliqué tel quel à des images privées dont le contenu varie selon l’utilisateur ou l’organisation.

Enregistrer uniquement les réponses 200 validées

En cas d’absence dans le cache, l’image est récupérée depuis un Service Binding privé. Nous validons le HTTP status, le Content-Type de l’image, le Content-Length et le body de la réponse, puis n’enregistrons que les réponses 200 qui satisfont ces conditions. Les réponses partielles, les bodies vides, les metadata invalides et les réponses d’échec ne sont pas enregistrés.

Enregistrer le contenu de l’image est différent du retour d’un 304 lorsque l’ETag correspond. Les écritures du cache sont planifiées avec waitUntil ; une erreur de lecture ou d’écriture du cache ne doit pas empêcher de renvoyer une image valide récupérée depuis l’origine. Si le cache peut répondre à une requête ultérieure, la récupération par le Service Binding peut être évitée.

La Cloudflare Cache API décrit les requêtes conditionnelles avec ETag et le fonctionnement du cache par centre de données. Un HIT dans un centre de données ne signifie pas que tous les centres ont un HIT. Les en-têtes de réponse des Pages Functions ne peuvent pas être définis uniquement avec les _headers pour les fichiers statiques ; il faut les gérer dans la Function.

Gérer séparément les limites de l’API dynamique

La protection de l’API dynamique est une exigence distincte du cache des images. Dans ce cas, les GET des images publiques ont été exclus du comptage WAF ; après application du changement, nous avons relu les API dynamiques ciblées, la période de limite, l’action et l’état d’activation. L’ancienne configuration a également été conservée pour le retour arrière.

Choisissez les seuils en fonction du nombre de requêtes générées par une navigation normale et de la charge de l’opération protégée. Il faut aussi vérifier les conditions propres au plan de la limitation de débit Cloudflare. La présence d’une valeur dans une note d’exploitation du dépôt ne prouve pas qu’une règle soit active en production.

1. 1 GET d’image publique Vérifiez la frontière de la requête, puis réutilisez la même image depuis le cache. Ne stockez que les réponses 200 validées.
2. 2 API dynamique Protégez le traitement avec le WAF et la quota applicative. Ces limites sont distinctes du cache des images.

Vérifier le contenu des images en production

Les tests unitaires ont couvert la réutilisation de la même image publique, la séparation par host et asset ID, la vérification de la frontière avant l’usage du cache, les réponses 304, les défaillances du cache et les réponses à ne pas enregistrer. Après la CI, nous avons confirmé le déploiement en production via un push GitHub et le domaine personnalisé, puis comparé le résultat HTTP d’images représentatives, l’état HIT ou MISS indiqué par l’application et le hash des bytes récupérés.

En production, nous avons aussi récupéré le contenu et plusieurs images à la suite, et confirmé que les requêtes n’étaient pas limitées dans cette condition de test de navigation normale. Il s’agit d’un contrôle d’un scénario de requêtes limité, et non d’un test de la frontière sous forte charge.

L’affichage de l’état du cache ne prouve pas à lui seul que la bonne image a été renvoyée. Nous vérifions séparément la récupération du contenu, celle des images, la configuration du WAF et le résultat de consultation dans l’UI. Ce compte rendu confirme la livraison d’images représentatives ; il ne démontre ni une consultation continue par tous les utilisateurs et dans tous les centres de données, ni des gains de performance sous forte charge.

Pour la répartition entre parties statiques et dynamiques du site, consultez la conception générale d’Astro et Cloudflare. Pour optimiser la livraison des images, du CSS et des autres ressources, consultez l’optimisation des performances d’Astro.