it-swarm.com.de

Kein Cache-Control-Header für Dateien aus AWS CloudFront mit S3 Origin

Wir sind gerade auf Amazon AWS migriert. Wir haben derzeit eine EC2-Instanz, die gut funktioniert. Es läuft Nginx vorne und Apache im Backend. Das läuft auch gut. Alle Sites werden ordnungsgemäß gestartet und enthalten den Cache-Control-Header für Dateien, die vom EC2 bereitgestellt werden.

Das Problem liegt bei ALLEN statischen Dateien, die wir in Amazon S3 abgelegt haben und auf die über CloudFront CDN zugegriffen wird . Wir können problemlos auf die Dateien zugreifen (und kein Problem mit CORS), aber anscheinend CloudFront liefert keine Dateien mit Cache-Control-Header. Wir möchten Hebelwirkung beim Browser-Caching.

Aus meiner Sicht spielt die EC2-Instanz hier keine Rolle, da die statischen Dateien direkt von S3 + CloudFront bereitgestellt werden und die Anforderung nicht an den Webserver in EC2 gesendet wird.

Ich bin völlig verloren.

Frage: 1) Wie stelle ich in diesem Fall das Cache-Control ein? 2) Ist es möglich das Cache-Control einzustellen? Von S3 oder CloudFront?

Hinweis: Ich habe einige Seiten in Google aufgerufen, auf denen Sie den Header in S3 für einzelne Objekte festlegen können. Das ist wirklich keine produktive Art, dies zu tun, da es sich in meinem Fall um mehrere Objekte handelt.

Vielen Dank!

28
jarvis

Ich habe einige Seiten in Google aufgerufen, auf denen Sie den Header in S3 für einzelne Objekte festlegen können. Das ist wirklich keine produktive Art, dies zu tun, da es sich in meinem Fall um mehrere Objekte handelt.

Nun, "produktiv" oder nicht, so soll es tatsächlich funktionieren.

CloudFront fügt keine Cache-Control: - Header hinzu.

CloudFront Passt Through (und respektiert auch, sofern nicht anders konfiguriert) die Cache-Control: - Header von der Origin-Server, in diesem Fall S3.

Um Cache-Control: - Header zu erhalten, die von S3 beim Abrufen eines Objekts bereitgestellt werden, müssen diese beim Hochladen des Objekts in S3 bereitgestellt oder durch eine nachfolgende Put + Copy-Operation zu den Metadaten des Objekts hinzugefügt werden, die intern verwendet werden kann Kopieren Sie ein Objekt in S3 in sich selbst und ändern Sie dabei die Metadaten. Dies ist, was die Konsole hinter den Kulissen tut, wenn Sie Objektmetadaten bearbeiten.

Es gibt auch (falls Sie sich fragen) keine globale Einstellung in S3, um alle Objekte in einem Bucket zu zwingen, diese Header zurückzugeben - es ist ein Attribut pro Objekt.


Update: Lambda @ Edge ist eine neue Funktion in CloudFront , mit der Sie Trigger für Anforderungen und/oder Antworten zwischen auslösen können Viewer und Cache und/oder Cache und Origin, wobei in Node.js geschriebener Code für eine einfache Anforderungs-/Antwortobjektstruktur ausgeführt wird, die von CloudFront verfügbar gemacht wird.

Eine der Hauptanwendungen für diese Funktion ist das Bearbeiten von Headern. Während das oben Genannte noch korrekt ist - CloudFront selbst fügt kein Cache-Control Hinzu - ist es jetzt für eine Lambda-Funktion möglich, sie der Antwort hinzuzufügen das wird von CloudFront zurückgegeben.

In diesem Beispiel wird Cache-Control: public, max-age=86400 Nur hinzugefügt, wenn in der Antwort noch kein Cache-Control - Header vorhanden ist.

Wenn Sie diesen Code in einem Origin Response-Trigger verwenden, wird er jedes Mal ausgelöst, wenn CloudFront ein Objekt aus dem Origin abruft, und die Antwort wird geändert, bevor CloudFront sie zwischenspeichert.

'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);
};

Update (2018-06-20): Vor kurzem habe ich eine Feature-Anfrage an das CloudFront-Team gesendet, um die Konfiguration des statischen Ursprungs zu ermöglichen Antwort Header als Origin-Attribute, ähnlich wie statische Anfrage Header können jetzt hinzugefügt werden ... aber mit einem Twist, so dass jeder Header so konfiguriert werden kann, dass er nur bedingt hinzugefügt wird wenn der Origin diesen Header nicht in der Antwort angegeben hat) oder bedingungslos (Hinzufügen des Headers und Überschreiben des Headers von dann Origin, falls vorhanden).

Bei Feature-Anfragen erhalten Sie normalerweise keine Bestätigung darüber, ob sie tatsächlich über die Implementierung des neuen Features nachdenken ... oder ob sie möglicherweise bereits daran gearbeitet haben ... es wird nur angekündigt, wenn sie fertig sind. Ich habe also keine Ahnung, ob diese implementiert werden. Es muss argumentiert werden, dass diese Funktion, da sie bereits über Lambda @ Edge verfügbar ist, in der Basisfunktionalität nicht erforderlich ist. Mein Gegenargument ist jedoch, dass die Basisfunktion ohne die Möglichkeit dazu nicht vollständig ist Führen Sie eine einfache Manipulation des statischen Antwortheaders durch. Wenn dies der einzige Grund ist, warum ein Trigger benötigt wird, ist das Erfordernis von Lambda-Triggern finanziell und mit zusätzlicher Latenz unnötig (auch wenn dies nicht unbedingt ein ausgefallener Kostenfaktor ist).

32