Gist:conflitti risposta in cache non CORS con nuove CORS richiedere
ho una pagina che utilizza tag di caricamento di un'immagine da S3 (HTML img
tag) e ho una pagina che utilizza xmlhttprequest
. Il caricamento dei tag viene memorizzato nella cache senza le intestazioni CORS e quindi lo xmlhttprequest
vede la versione memorizzata nella cache, controlla le intestazioni e fallisce con un errore di origine incrociata.
Dettagli:
modificare: non riesce in entrambi Safari 5.1.6 e Chrome 21.0.1180.89. Funziona bene in Firefox 14.
Utilizzando nuove CORS di S3, a configurare una CORSRule
come così:
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>0</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
Se richiedo un'immagine da S3 senza impostare l'origine nelle intestazioni di richiesta torno l'immagine senza eventuali intestazioni CORS nella risposta.
Questa richiesta viene memorizzata nella cache e le successive richieste CORS (le quali impostano l'origine nell'intestazione della richiesta) vengono rifiutate poiché il browser utilizza la versione non CORS della cache.
Qual è il modo migliore per risolvere questo problema? Posso impostare qualcosa in modo che la versione non CORS non venga mai salvata nella cache? Devo differenziare le richieste CORS aggiungendo un ?some_flag
all'URL della richiesta?
Idealmente avrei S3 SEMPRE inviare le intestazioni CORS necessarie anche se la richiesta non contiene "origine".
Che browser stai utilizzando? Questo comportamento si verifica in tutti i browser? Sembra un bug del browser. La soluzione del parametro di query che proponi sembra una buona soluzione. – monsur
aggiunto "edit: errore in entrambi i safari 5.1.6 e chrome 21.0.1180.89. Funziona bene in firefox 14." – Wes
Probabilmente un bug WebKit allora. Sembra lo stesso problema: https://bugs.webkit.org/show_bug.cgi?id=63090 Il bug suggerisce che l'aggiunta dell'intestazione "Vary: Origin" potrebbe risolvere il problema. – monsur