Ho toccato alcune pagine di Google in cui è possibile impostare l'intestazione in S3 per singoli oggetti. Questo non è davvero un modo produttivo per farlo specialmente perché nel mio caso stiamo parlando di diversi oggetti.
Bene, "produttivo" o no, è così che effettivamente è progettato per funzionare.
CloudFront non aggiunge le Cache-Control: intestazioni.
CloudFront passa attraverso (e rispetta anche, se non diversamente configurato) le Cache-Control:intestazioni fornite dal server di origine, che in questo caso è S3.
Per ottenere le Cache-Control:intestazioni fornite da S3 quando un oggetto viene recuperato, devono essere fornite quando l'oggetto viene caricato in S3 o aggiunte ai metadati dell'oggetto mediante una successiva operazione put + copia, che può essere utilizzata per copiare internamente un oggetto in se stesso in S3, modificando i metadati nel processo. Questo è ciò che fa la console, dietro le quinte, se si modificano i metadati degli oggetti.
Inoltre, nel caso in cui non ti stia chiedendo, non esiste alcuna impostazione globale in S3 per forzare tutti gli oggetti in un bucket a restituire queste intestazioni: è un attributo per oggetto.
Aggiornamento: Lambda @ Edge è una nuova funzionalità di CloudFront che consente di attivare trigger contro richieste e / o risposte, tra visualizzatore e cache e / o cache e origine, eseguendo codice scritto in Node.js su una semplice struttura di oggetti richiesta / risposta esposto da CloudFront.
Una delle principali applicazioni di questa funzione è la manipolazione delle intestazioni ... quindi, sebbene quanto sopra sia ancora accurato - CloudFront stesso non aggiunge Cache-Control- è ora possibile per una funzione Lambda aggiungerle alla risposta che viene restituita da CloudFront.
Questo esempio aggiunge Cache-Control: public, max-age=86400solo se non è Cache-Controlgià presente un'intestazione sulla risposta.
L'uso di questo codice in un trigger di risposta all'origine lo farebbe scattare ogni volta che CloudFront recupera un oggetto dall'origine e modifica la risposta prima che CloudFront lo memorizzi nella 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);
};
Aggiornamento (20/06/2018): di recente ho inviato una richiesta di funzionalità al team CloudFront per consentire la configurazione delle intestazioni di risposta all'origine statica come attributi di origine, in modo simile al modo in cui è possibile aggiungere intestazioni di richiesta statica , ora ... ma con un twist, consentendo a ciascuna intestazione di essere configurata per essere aggiunta in modo condizionale (solo se l'origine non ha fornito quell'intestazione nella risposta) o incondizionatamente (aggiungendo l'intestazione e sovrascrivendo l'intestazione da allora origine, se presente).
Con le richieste di funzionalità, in genere non si riceve alcuna conferma del fatto che stiano effettivamente prendendo in considerazione l'implementazione della nuova funzionalità ... o anche se potrebbero aver già lavorato su di essa ... viene appena annunciato al termine. Quindi, non ho idea se questi saranno implementati. C'è un argomento da sostenere sul fatto che poiché questa funzionalità è già disponibile tramite Lambda @ Edge, non è necessario nella funzionalità di base ... ma il mio contro-argomento è che la base non è funzionalmente completa senza la possibilità di eseguire una semplice manipolazione dell'intestazione della risposta statica e che se questa è l'unica ragione per cui è necessario un trigger, la richiesta di trigger Lambda è un costo non necessario, finanziariamente e con una latenza aggiuntiva (anche se nessuno dei due è necessariamente un costo stravagante).