Forzare CloudFront a passare l'ultimo file HTML da S3

sfondo

Sto ospitando un sito statico su S3, con CloudFront sopra le righe. Il problema che ho è con i miei file HTML.

Secondo le FAQ di CloudFront :

Amazon CloudFront utilizza queste intestazioni di controllo della cache per determinare con quale frequenza deve controllare l'origine per una versione aggiornata di quel file

Quello che ho fatto finora

Con questo in mente ho impostato i file HTML nel mio bucket S3 per aggiungere le seguenti intestazioni:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Expires: Fri, 01 Jan 1990 00:00:00 GMT

Alla mia prima chiamata al mio samplefile.htm, vedo le seguenti intestazioni di risposta (ho escluso le intestazioni ovvie (ad es. Content-Type) Per mantenere il punto:

Cache-Control:no-cache, no-store, max-age=0, must-revalidate
Date:Sat, 10 Dec 2011 14:16:51 GMT
ETag:"a5890ace30a3e84d9118196c161aeec2"
Expires:Fri, 01 Jan 1990 00:00:00 GMT
Last-Modified:Sat, 10 Dec 2011 14:16:43 GMT
Server:AmazonS3
X-Cache:Miss from cloudfront

Come puoi vedere, la mia Cache-Controlintestazione è lì. Il problema è che se aggiorno questo file e aggiorno ottengo il contenuto memorizzato nella cache (anziché l'ultimo file) e posso vedere che CloudFront sta offrendo la sua versione memorizzata nella cache osservando le intestazioni di risposta:

X-Cache:Hit from cloudfront

Sintesi / domanda

Tenendo presente quanto sopra, come posso ottenere il recupero automatico dell'ultimo HTML quando utilizzo CloudFront?

Secondo le sue FAQ dovrei essere in grado di farlo con le intestazioni Cache-Control, ma non riesco a farlo funzionare.

Seguendo le risposte di seguito

Alla fine ho deciso di cambiare il mio CNAME www per puntare direttamente al mio bucket S3. Quindi aggiunto un nuovo CNAME chiamato "statico", che punta a CloudFront.

Ciò significa che HTML è diretto da S3, che ha quindi tutti i suoi riferimenti CSS / JS / IMG che puntano a static.mydomain.com

In primo luogo, il punto di Cloudfront è quello di servire il contenuto memorizzato nella cache - se si tenta di servire il contenuto non memorizzato nella cache da Cloudfront, è più lento rispetto alla pubblicazione diretta da S3, in quasi tutti i casi (qualcosa come lo streaming di contenuti sarebbe l'eccezione). Considera per un momento cosa deve accadere per servire il contenuto da Cloudfront - deve essere recuperato dal server di origine in una posizione geograficamente vicina all'utente - il che significa che per una richiesta in cui Cloudfront deve recuperare il contenuto dal server di origine , aggiungi ulteriore latenza alla richiesta e l'utente riceve i contenuti più lentamente. È solo una volta che il contenuto è disponibile nella posizione limite che le richieste successive sono più veloci.

L'approccio migliore a questo problema è quello di cambiare i nomi dei file quando si aggiorna una pagina - questo costringerà Cloudfront a recuperare il nuovo contenuto. Ancora una volta, tieni presente che Cloudfront è in genere utilizzato per i file multimediali (comprese le immagini) e style / javascript - e non tanto per l'html. In sostanza, avresti il ​​tuo HTML su S3 e le tue immagini su Cloudfront - con qualsiasi modifica apportata, puoi cambiare il nome del file su Cloudfront (es. File-v1.jpg, file-v2.jpg, ecc.). Un altro modo comune è includere una stringa di query con informazioni sulla versione.

Inoltre, tieni presente che Cloudfront non offre contenuti compressi con gzip, il che può comportare una risposta più lenta rispetto a un normale server (anche se, nel tuo caso, S3 non identifica neanche i browser compatibili con gzip).

Infine, se lo desideri, puoi utilizzare l'invalidazione per forzare Cloudfront a scartare la sua copia esistente e prenderne una nuova dal server di origine. Nota, tuttavia, che Cloudfront ti offre solo 1000 invalidazioni gratuite al mese, dopo di che il costo è di $ 0,005 / invalidazione.

Il tempo più basso in cui Cloudfront manterrà il contenuto è 1 ora , sebbene l'impostazione predefinita sia 24 ore. Proverei quindi a impostare il max-age su almeno 3600. Considera anche un'intestazione s-maxage (per i contenuti condivisi, ovvero proxy). Amazon consiglia questo tutorial di memorizzazione nella cache.

Si è verificato un problema recente , risolto alcuni giorni fa

Credo che le risposte finora, sebbene siano corrette al momento, non sono più aggiornate, poiché Cloudfront ora supporta un TTL minimo di 0 e il tentativo originale dell'OP di utilizzare cache-age = 0 ora dovrebbe funzionare.

Dovresti esaminare se utilizzare quelle altre intestazioni di controllo della cache, in termini di se produrranno il risultato che stai cercando - potresti aver bisogno solo di max-age. Quello che probabilmente vuoi è che Cloudfront controlli S3 per vedere se il file HTML è cambiato. In tal caso, Cloudfront può recuperare e restituire il nuovo file. In caso contrario, può servire il client dalla sua cache esistente (preservando la larghezza di banda S3 e servendo il client più velocemente e più localmente).

Il punto di Cloudfront è quello di pubblicare contenuti memorizzati nella cache, sì, ma ora questo include contenuti che a volte cambiano, ma possono essere memorizzati nella cache se non sono cambiati.

Le stringhe di query ps ora funzionano anche con Cloudfront (se si configura un "comportamento" per l'origine pertinente, un'altra nuova funzionalità), tuttavia alcuni proxy potrebbero non riuscire a memorizzare nella cache qualsiasi file con stringhe di query.

Guida per gli sviluppatori Amazon: Scadenza 1

Non sei sicuro di come CloudFront tratti l'intestazione come quella che hai, ma se non specifichi nessuna intestazione, il tempo predefinito per aggiornare gli oggetti è di 24 ore.

Una delle cose che puoi fare per aggiornare gli oggetti è invalidare il contenuto. Controlla il link qui sotto per maggiori informazioni. http://blog.cloudberrylab.com/2010/08/how-to-manage-cloudfront-object.html