J'ai personnalisé la mise en cache des objets sur ma distribution CloudFront. Pourquoi est-ce que la distribution utilise les paramètres de cache de l'origine ?

Lecture de 6 minute(s)
0

La distribution Amazon CloudFront a un comportement de cache avec la mise en cache d'objet définie sur Customize (Personnaliser), mais la distribution utilise toujours les paramètres de cache de l'origine. Comment corriger ce problème ?

Brève description

Lorsque vous personnalisez la mise en cache d'objet, vous configurez la durée de vie par défaut, la durée de vie minimale, et la durée de vie maximale. CloudFront utilise ces paramètres selon si l'origine renvoie un en-tête de mise en cache ou non :

  • Si l'origine ne renvoie pas d’en-tête de mise en cache, la distribution utilise la durée de vie par défaut.
  • Si l'origine renvoie un en-tête de mise en cache inférieur à la durée de vie minimale, alors la distribution utilise la durée de vie minimale.
  • Si l'origine renvoie un en-tête de mise en cache supérieur à la durée de vie maximale, alors la distribution utilise la durée de vie maximale.

Remarque : la réponse au client contient les en-têtes de mise en cache d'origine même lorsque CloudFront met en cache la réponse en fonction de la durée de vie minimale ou maximale. L'en-tête de mise en cache d'origine peut être utilisé par n'importe quel cache privé, par exemple celui d'un navigateur ou d'un proxy.

Si votre distribution CloudFront n’effectue pas la mise en cache en fonction des valeurs personnalisées que vous définissez dans les comportements de cache, alors vérifiez l'origine. Vérifiez si l'origine a des en-têtes de mise en cache contradictoires.

Solution

Pour vérifier si les en-têtes de mise en cache d'origine sont en conflit avec la mise en cache d’objets personnalisée de votre distribution, suivez ces instructions en fonction des problèmes que vous voyez :

Les durées de vie minimale et par défaut sont définies sur zéro, mais il y a tout de même des hits à partir de CloudFront

S'il y a des hits à partir de CloudFront, même si un URI de demande correspond à un chemin de comportement de cache avec une durée de vie minimale et une durée de vie par défaut définies sur zéro, alors vérifiez la réponse de CloudFront. Regardez si la réponse montre l’en-tête X-Cache en tant que « Hit from cloudfront » (Hit de Cloudfront) ou « RefreshHit from cloudfront » (RefreshHit de Cloudfront) :

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: max-age=300, Public
< Accept-Ranges: bytes
< Server: AmazonS3
< Age: 14
< X-Cache: Hit from cloudfront

Si l'en-tête X-Cache est« Hit from cloudfront » (Hit de Cloudfront) ou « RefreshHit from cloudfront » (RefreshHit de Cloudfront), alors la demande vient de la mémoire cache de l'emplacement périphérique.

Examinez le reste de la réponse pour les en-têtes Cache-Control, Expires, et Age. Les en-têtes Cache-Control et Expires sont des en-têtes de mise en cache comportementaux qui indiquent à l'intermédiaire (CloudFront) ou au cache privé (navigateur) comment stocker une demande. L'en-tête Age indique la durée pendant laquelle une réponse a été mise en cache.

Si la valeur max-age de Cache-Control est supérieure à la valeur d’Age, la réponse en cache est considérée comme nouvelle et elle est diffusée depuis l'emplacement périphérique. Si la date Expires n’est pas encore passée, la réponse en cache est également considérée comme nouvelle. Cela se produit même si le chemin de comportement de cache a une durée de vie minimale et une durée de vie par défaut définies sur zéro.

Les durées de vie maximale et par défaut sont supérieures à zéro, mais il y a des échecs de CloudFront

S'il existe des échecs de CloudFront, même si un URI de demande correspond à un chemin de comportement de cache avec des durées de vie maximale et par défaut définies sur des valeurs supérieures à zéro, vérifiez la réponse de CloudFront. Vérifiez si la réponse affiche pour l'en-tête X-Cache « Miss from cloudfront » (Échec de Cloudfront) :

< HTTP/1.1 200 OK
< Content-Type: text/html
< Content-Length: 437
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 19:26:45 GMT
< Last-Modified: Sat, 03 Feb 2018 19:25:24 GMT
< ETag: "example12345abcdefghijklmno54321"
< Cache-Control: no-cache, no-store
< Accept-Ranges: bytes
< Server: AmazonS3
< X-Cache: Miss from cloudfront

Si l'en-tête X-Cache affiche « Miss from cloudfront » (Échec de Cloudfront), alors la demande a été récupérée depuis l'origine et n'a pas été diffusée par le cache.

Vérifiez l'en-tête Cache-Control dans la réponse. Si la valeur de Cache-Control est « no-store », alors l'en-tête dirige CloudFront de manière à ne pas mettre en cache la réponse. Si la valeur de Cache-Control est « no-cache », alors l'en-tête dirige CloudFront de manière à ce qu'il vérifie avec l'origine avant de renvoyer une réponse en cache. Ces directives remplacent les durées de vie maximale et par défaut définies dans les paramètres CloudFront.

Remarque : les réponses qui ne proviennent pas du cache n'auront pas d'en-tête Age.

CloudFront met en cache des réponses d'erreur

Par défaut, CloudFront transmet les réponses d'erreur de l'origine au client. De plus, CloudFront met en cache la réponse d'erreur de l'origine pendant 10 secondes par défaut.

Si la réponse d'erreur de l'origine contient un en-tête Cache-Control, CloudFront met en cache l'erreur avec la durée de vie pertinente au lieu de la valeur par défaut de 5 minutes. CloudFront ne met pas en cache ses propres réponses d'erreur, sauf mention contraire dans une réponse d'erreur personnalisée.

Pour déterminer si la réponse d'erreur provient de l'origine ou de CloudFront, regardez l’en-tête Server. Pour déterminer si l'erreur est une réponse en cache, regardez l’en-tête Age. Une réponse en cache inclut un en-tête Age.

L'exemple suivant est une erreur provenant d’une origine Amazon Simple Storage Service (Amazon S3) qui est une réponse en cache :

< HTTP/1.1 403 Forbidden
< Content-Type: application/xml
< Transfer-Encoding: chunked
< Connection: keep-alive
< Date: Sat, 03 Feb 2018 21:07:51 GMT
< Server: AmazonS3
< Age: 12
< X-Cache: Error from cloudfront

L'exemple suivant est une erreur de CloudFront qui n'est pas une réponse en cache :

< HTTP/1.1 403 Forbidden
< Server: CloudFront
< Date: Sat, 03 Feb 2018 21:14:53 GMT
< Content-Type: text/xml
< Content-Length: 146
< Connection: keep-alive
< X-Cache: Error from cloudfront

Une fois que vous avez identifié les en-têtes de mise en cache contradictoires, mettez à jour l'origine

Une fois que vous avez déterminé quels en-têtes de mise en cache se substituent à la mise en cache d'objets personnalisée de votre distribution, procédez comme suit :

  1. Identifiez où dans la configuration du serveur web les en-têtes sont appliqués.
  2. Supprimez les lignes où les en-têtes sont appliqués.
  3. Redémarrez le serveur.
  4. Testez votre origine directement pour être sûr que les en-têtes de mise en cache ne sont plus retournés dans la réponse.
  5. Exécutez une invalidation sur l'ensemble de la distribution CloudFront pour appliquer la modification.

Informations connexes

Mise en cache de contenu basée sur des en-têtes de requêtes

AWS OFFICIEL
AWS OFFICIELA mis à jour il y a 2 ans