2011-01-21 11 views
8

Stiamo sviluppando un grande sito Web e tutte le nostre immagini e risorse sono in Amazon S3. Stiamo anche utilizzando Cloudfront per distribuire il nostro contenuto a livello globale. Quello che vogliamo fare è dire al browser web del client di memorizzare nella cache i nostri file, perché quando li cambiamo, cambieremo anche l'URL (Cloudfront non riflette la modifica per 24 ore altrove).Quando si utilizza Cloudfront, come si può impostare l'intestazione di scadenza rispetto alla data corrente?

Attualmente stiamo utilizzando ETags ma questo non è ottimale becaue il Cliente deve ancora fare la richiesta per verificare se la risorsa è cambiato.

Una soluzione sarebbe l'intestazione Expires, ma non abbiamo trovato un modo per impostarlo relativamente alla data corrente, come possibile nella configurazione di Apache per S3, e non possiamo aggiornare regolarmente tutto il contenuto, perché è praticamente. Pertanto, avremmo bisogno di un'opzione di configurazione che imposta l'intestazione di scadenza su una data relativa alla data corrente per tutto il contenuto.

Un'altra soluzione potrebbe essere quella di impostare Cache-Control: max-age ad un certo valore. funziona? È accettato dai principali browser? Distruggerò alcuni algoritmi di caching con questo? Perché YSlow consiglia di impostare l'intestazione Expires ma non Cache-Control: max-age?

Altre eventuali raccomandazioni? Stiamo comprimendo CSS e JS, usando Sprites dove è plausibile, impostando le intestazioni Expires e gli ETags dove è possibile, e presto comprimeremo le nostre immagini con lo strumento di compressione di Yahoo e l'output di gzipping.

risposta

3

Abbiamo fatto qualche ricerca su noi stessi. Sembra che l'intestazione Cache-Control aiuta con raccontando Cloudfront o un proxy per impostare una valida Expires, ma solo qualche volta ...

Attualmente stiamo scrivendo un Cron Job per aggiornare tutte le intestazioni nella S3 regolarmente, perché questo è una cosa che funziona di sicuro. Sembra che non ci sia altro modo. Ti terrò informato se c'è.

+0

Ciao Paul, ho lo stesso problema, hai gestito una soluzione migliore? – ic3

+0

No, AFAIK non esiste una soluzione migliore. –

+0

@PaulWeber è possibile condividere un succo di quello che avete fatto Ho anche bisogno di fare simile genere di cose – msonowal

2

Perché avete bisogno la durata della cache per essere relativo alla data corrente?

hai detto:

"quando li cambiamo, ci sarà anche modificare l'URL"

Che per me significa che le risorse mai cambiamento. Perché non impostare un Expire Header su una data futura molto lontana (ad esempio il 01/01/2020)?

+0

Buona idea. Non sono sicuro del motivo per cui abbiamo abbandonato questa soluzione, ma penso che fosse perché se la data di scadenza è troppo lontana in futuro, alcuni browser o Proxys la ignoreranno. Al momento lasciamo che i nostri contenuti scadano tra 1 anno, funziona, ma potremmo provare ad aumentarlo. Sezione 14.21 –

+1

[RFC-2616] (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) dice: "Per contrassegnare una risposta come 'non scade mai,' un server di origine invia una data di scadenza di circa un anno dal momento in cui viene inviata la risposta, i server HTTP/1.1 NON DEVONO inviare date di scadenza più di un anno in futuro. " Se questo è effettivamente un problema nella pratica, non lo so. – Carson63000

Problemi correlati