Síntesis:caché conflictos de respuesta no CORS con nuevos CORS solicitan
tengo una página que utiliza la etiqueta de carga de una imagen de s3 (HTML img
etiqueta) y tengo una página que utiliza xmlhttprequest
. La carga de la etiqueta se almacena en caché sin los encabezados CORS, por lo que el xmlhttprequest
ve la versión en caché, comprueba sus encabezados y falla con un error de origen cruzado.
Detalles:
de edición: se produce un error, tanto en Safari 5.1.6 y cromo 21.0.1180.89. Funciona bien en Firefox 14.
Usando nuevos CORS de S3, I fijó un CORSRule
como tan:
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
<AllowedMethod>HEAD</AllowedMethod>
<MaxAgeSeconds>0</MaxAgeSeconds>
<AllowedHeader>*</AllowedHeader>
</CORSRule>
Si solicito una imagen de S3 sin establecer el origen en las cabeceras de petición le regreso la imagen sin cualquier encabezado CORS en la respuesta.
Este get caché y las subsiguientes solicitudes CORS (una que establece el origen en el encabezado de la solicitud) son rechazadas ya que el navegador usa la versión no CORS del caché.
¿Cuál es la mejor manera de resolver esto? ¿Puedo configurar algo para que la versión que no es CORS nunca se almacene en la memoria caché? ¿Debo diferenciar las solicitudes de CORS al anexar un ?some_flag
a la url de la solicitud?
Lo ideal sería que S3 SIEMPRE devuelva los encabezados CORS necesarios, incluso si la solicitud no contiene "origen".
¿Qué navegador estás usando? ¿Este comportamiento ocurre en todos los navegadores? Esto suena como un error del navegador. La solución de parámetros de consulta que propone parece una buena solución. – monsur
agregó "editar: falla en safari 5.1.6 y en cromo 21.0.1180.89. Funciona bien en firefox 14." – Wes
Probablemente un error WebKit entonces. Esto suena como el mismo problema: https://bugs.webkit.org/show_bug.cgi?id=63090 El error sugiere que agregar el encabezado "Variar: Origen" puede abordar el problema. – monsur