Come dire a cloudfront di non memorizzare nella cache 302 risposte dai reindirizzamenti S3, o, in che altro modo di risolvere questo problema di generazione di cache di immagini

Question

Sto usando Imagine tramite LIIPImagineBundle per Symfony2 per creare versioni cache di immagini memorizzate in S3.

Le immagini memorizzate nella cache sono archiviate in un bucket S3 abilitato per il web offerto da CloudFront. Tuttavia, l'implementazione di S3 di LIIPImagineBundle è troppo lenta per me (controllando se il file esiste su S3, quindi creando un URL sul file memorizzato o sulla funzionalità di risoluzione), quindi ho elaborato il mio flusso di lavoro:

1. client passare l'URL CloudFront in cui l'immagine memorizzata nella cache dovrebbe esistere
2. client richiede l'immagine tramite l'URL CloudFront, se non esiste, allora il secchio S3 ha una regola di reindirizzamento, che 302 reindirizza l'utente a una immaginare percorso webserver che genera la versione cache del file e lo salva nella posizione appropriata su S3
3. Il reindirizzamento webserve 301 s l'utente torna all'URL del cloudfront in cui l'immagine è ora memorizzata e al client viene servita l'immagine.

Questo funziona bene fino a quando non utilizzo cloudfront. Il problema sembra essere che il cloudfront sta memorizzando nella cache la risposta di reindirizzamento 302 (anche se la specifica http afferma che non dovrebbero). Pertanto, se utilizzo il cloudfront, il client viene inviato in un ciclo di reindirizzamento infinito avanti e indietro dal server web al cloudfront e ogni richiesta successiva al file reindirizza ancora al server Web anche dopo che il file è stato generato.

Se utilizzo S3 direttamente anziché cloudfront, non ci sono problemi e questa soluzione è solida.

Secondo Amazon's documentation Le regole di reindirizzamento S3 non consentono di specificare intestazioni personalizzate (per impostare intestazioni di controllo della cache o simili) e non credo che CloudFront mi consenta di controllare la memorizzazione nella cache dei reindirizzamenti (se essi è ben nascosto). Le opzioni di invalidazione di CloudFront sono così limitate che non penso che funzioneranno (possono invalidare solo 3 oggetti in qualsiasi momento) ... Potrei passare un argomento a cloudfront sul primo reindirizzamento (dal server Web Imagine) per correggere l'infinito reindirizzamento (ad esempio image.jpg? 1), ma le successive richieste allo stesso oggetto rimarranno 302 al server web e quindi 301 al cloudfront anche se esiste. Sento che dovrebbe esserci una soluzione elegante a questo problema, ma mi sfugge. Qualsiasi aiuto sarebbe apprezzato!!

Answer 1

Se è davvero necessario utilizzare CloudFront qui, l'unica cosa che posso pensare è che non si sottopone direttamente l'utente alla danza 302, 301. Potresti introdurre una specie di script/pagina proxy per far fronte a S3 e all'intero processo? (o lo fa quindi sconfiggere il punto).

Quindi un cache miss sarebbe simile a questa:

• Visitor pagina richieste di procura attraverso Cloudfront.
• pagina Proxy richiede un'immagine da S3
• pagina proxy riceve 302 da S3, segue questa Imagine web server di
• Idealmente solo riportare l'immagine da qui (mentre lasciandolo aggiornare S3), o seguire 301 di nuovo a S3
• pagina proxy restituisce un'immagine al visitatore
• immagine viene memorizzata nella cache dal Cloudfront

Answer 2

sto risolvere questo stesso problema impostando il "TTL di default" in CloudFront "cache Beha viore "le impostazioni su 0, ma consentono comunque di memorizzare nella cache le immagini ridimensionate impostando il valore CacheControl MetaData sul file S3 con max-age=12313213.

In questo modo i reindirizzamenti non verranno memorizzati nella cache (comportamento TTL predefinito), ma le immagini ridimensionate saranno (CacheControl max-age su hit cache s3).