Kann ich in Amazon S3 eine Variable "Expires" festlegen?

Ich habe eine Menge Dateien in Amazon S3 (über Cloudfront bereitgestellt), für die ich einen Expires-Header von hinzugefügt habe Mon, Jan 1 2024 11:11:11 GMT

Ich habe jedoch kürzlich erfahren, dass das Setzen eines Expires-Headers für mehr als ein Jahr in der Zukunft gegen den HTTP 1.1-RFC verstößt .

Gibt es in S3 eine Möglichkeit, ein dynamisches Ablaufdatum festzulegen, das immer ein Jahr nach dem Anforderungsdatum liegt?

http-headers amazon-s3 expires

— DisgruntledGoat
quelle

Gibt es in S3 eine Möglichkeit, ein dynamisches Ablaufdatum festzulegen, das immer ein Jahr nach dem Anforderungsdatum liegt?

Nicht, dass ich wüsste, und ich bezweifle, dass das AWS-Team eine engagierte Unterstützung dafür in Betracht ziehen wird:

Sie wissen wahrscheinlich, dass ein dynamischer Expires: ...Wert nicht als solcher festgelegt werden kann, da der einzige in einem Expires-Header gültige Wert ein HTTP-Datum ist. Alles andere wird höchstwahrscheinlich als "in der Vergangenheit" interpretiert, so dass die Darstellung nicht zwischengespeichert werden kann. (Siehe z. B. Steuern der Aktualität mit dem Ablauf-HTTP-Header in Mark Nottinghams ausgezeichnetem Caching-Tutorial ).

Diese Schwäche des HTTP 1.0- Expires: ...Headers wurde jedoch in HTTP 1.1 erkannt und behoben, mit dem eine neue Klasse von Headern, Cache-Control-Antwortheader, eingeführt wurde, um Web-Publishern mehr Kontrolle über ihren Inhalt zu geben und die Einschränkungen von Expires zu beseitigen. (Siehe Cache-Control-HTTP-Header ).

In Bezug auf Ihren Anwendungsfall (und im Allgemeinen) würde ich dringend empfehlen, zunächst ein Cache-Control: max-age=...Jahr lang auf einen Header zurückzugreifen und die Expires: ...Abwärtskompatibilität nur dann hinzuzufügen , wenn es einen bestimmten Grund dafür gibt. In diesem Fall müssen Sie jedoch entsprechend Ihrer Frage den Wert tatsächlich gelegentlich anpassen, um eine Verletzung des HTTP 1.1-RFC zu vermeiden, z. B. über ein Skript, das auf die S3-API abzielt .

— Steffen Opel
quelle

Danke für eine tolle Antwort. Noch eine kurze Frage: Wissen Sie, ob "public" in der Cache-Control-Direktive erforderlich ist, oder ist dies die Standardeinstellung? dhCache-control: public, max-age=3600

— DisgruntledGoat

Dies ist nicht die Standardeinstellung, sondern die Cachefähigkeit hängt vom Kontext ab (z. B. ist die Standardeinstellung für HTTP-authentifizierte Anforderungen privat). Die Details sind etwas komplex, siehe Was ist zwischenspeicherbar? und Response - Cachefähigkeit , dh es ist eine Art in den meisten Szenarien implizit, aber über Ihre Benutzung Fall erscheint es sinnvoll , um es hinzuzufügen, sofern Sie wahrscheinlich Cache authentifizierten Antworten wollen würden auch (falls vorhanden) ?!

— Steffen Opel

Wie üblich ist die Zusammenfassung in Mark Nottinghams Cache-Control-HTTP-Headern viel einfacher zu verstehen. Ich denke, schauen Sie sich die Erklärung für publicund insbesondere an no-cache, die die Auswirkungen der ersteren erweitert.

— Steffen Opel