web-dev-qa-db-fra.com

Aucun en-tête de contrôle de cache pour les fichiers d'AWS CloudFront avec S3 Origin

Nous venons de migrer vers Amazon AWS. Nous avons actuellement une instance EC2 qui fonctionne bien. Il exécute Nginx à l'avant et Apache à l'arrière. Ça marche bien aussi. Tous les sites sont lancés correctement et incluent l'en-tête Cache-Control pour les fichiers qui sont servis à partir de l'EC2.

Le problème vient de TOUS les fichiers statiques que nous avons placés dans Amazon S3 accessible via CloudFront CDN . Nous pouvons accéder aux fichiers très bien (et aucun problème avec CORS), mais apparemment CloudFront ne sert pas les fichiers avec l'en-tête Cache-Control. Nous voulons tirer parti de la mise en cache du navigateur.

De mon point de vue, l'instance EC2 ne joue aucun rôle ici car les fichiers statiques sont servis directement par S3 + CloudFront, la requête ne va pas au serveur Web dans EC2.

Je suis complètement perdu.

Question: 1) Comment définir le Cache-Control dans ce cas? 2) Est-il possible de définir le Cache-Control? Depuis S3 ou CloudFront?

Remarque: J'ai visité quelques pages dans Google où vous pouvez définir l'en-tête dans S3 pour des objets individuels. Ce n'est vraiment pas une façon productive de le faire spécialement car dans mon cas, nous parlons de plusieurs objets.

Merci!

amazon-web-servicescacheamazon-s3cdnamazon-cloudfront
28
jarvis

J'ai visité quelques pages dans Google où vous pouvez définir l'en-tête dans S3 pour des objets individuels. Ce n'est vraiment pas une façon productive de le faire spécialement, car dans mon cas, nous parlons de plusieurs objets.

Eh bien, "productif" ou non, c'est ainsi qu'il est conçu pour fonctionner.

CloudFront n'ajoute pas Cache-Control: en-têtes.

CloudFront passe-travers (et respecte également, sauf indication contraire) le Cache-Control: en-têtes fournis par le serveur Origin, qui dans ce cas est S3.

Obtenir Cache-Control: en-têtes fournis par S3 lorsqu'un objet est récupéré, ils doivent être fournis lorsque l'objet est téléchargé dans S3, ou ajoutés aux métadonnées de l'objet par une opération put + copy ultérieure, qui peut être utilisée pour copier en interne un objet en lui-même dans S3, modifiant les métadonnées dans le processus. C'est ce que fait la console, en arrière-plan, si vous modifiez des métadonnées d'objet.

Il n'y a également (au cas où vous vous poseriez la question) aucun paramètre global dans S3 pour forcer tous les objets d'un compartiment à renvoyer ces en-têtes - c'est un attribut par objet.

Mise à jour: Lambda @ Edge est une nouvelle fonctionnalité dans CloudFront qui vous permet de déclencher des déclencheurs contre des demandes et/ou des réponses, entre visionneuse et cache et/ou cache et Origin, exécutant du code écrit dans Node.js sur une structure d'objet de demande/réponse simple exposée par CloudFront.

L'une des principales applications de cette fonctionnalité est la manipulation des en-têtes ... donc, bien que ce qui précède soit toujours précis - CloudFront lui-même n'ajoute pas Cache-Control - il est désormais possible pour une fonction Lambda de les ajouter à la réponse renvoyée par CloudFront.

Cet exemple ajoute Cache-Control: public, max-age=86400 uniquement s'il n'y a pas de Cache-Control en-tête déjà présent sur la réponse.

L'utilisation de ce code dans un déclencheur de réponse d'origine entraînerait son déclenchement à chaque fois que CloudFront récupère un objet de l'origine et modifiait la réponse avant que CloudFront ne le mette en cache.

'use strict';

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    if(!response.headers['cache-control'])
    {
        response.headers['cache-control'] = [{ 
            key:   'Cache-Control', 
            value: 'public, max-age=86400' 
        }];
    }

    callback(null, response);
};

Mise à jour (2018-06-20): Récemment, j'ai soumis une demande de fonctionnalité à l'équipe CloudFront pour permettre la configuration de l'origine statique réponse en-têtes en tant qu'attributs Origin, semblable à la façon dont les en-têtes statiques demande peuvent être ajoutés, maintenant ... mais avec une torsion, permettant à chaque en-tête d'être configuré pour être ajouté conditionnellement (uniquement si l'Origin n'a pas fourni cet en-tête dans la réponse) ou inconditionnellement (en ajoutant l'en-tête et en écrasant l'en-tête à partir d'Origine, le cas échéant).

Avec les demandes de fonctionnalités, vous ne recevez généralement aucune confirmation si elles envisagent réellement d'implémenter la nouvelle fonctionnalité ... ou même si elles ont peut-être déjà travaillé dessus ... c'est juste annoncé lorsqu'elles sont terminées. Donc, je n'ai aucune idée si ces derniers seront mis en œuvre. Il y a un argument à faire valoir que puisque cette capacité est déjà disponible via Lambda @ Edge, elle n'est pas nécessaire dans la fonctionnalité de base ... mais mon contre-argument est que la base n'est fonctionnellement pas complète sans la possibilité de faire une manipulation d'en-tête de réponse simple et statique, et que si c'est la seule raison pour laquelle un déclencheur est nécessaire, alors exiger des déclencheurs Lambda est un coût inutile, financièrement et avec une latence supplémentaire (même si aucun n'est nécessairement un coût bizarre).

32
Michael - sqlbot