2012-09-19 8 views
31

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".

+0

¿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

+0

agregó "editar: falla en safari 5.1.6 y en cromo 21.0.1180.89. Funciona bien en firefox 14." – Wes

+1

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

Respuesta

7

Me encontré con el mismo problema. Como dijo @monsur, el problema es que S3 no establece el encabezado "Vary: Origin", aunque debería. Desafortunadamente, hasta donde sé, no hay forma de que S3 envíe ese encabezado. Sin embargo, puede solucionar esto agregando un parámetro de cadena de consulta a la solicitud como ?origin=example.com cuando necesite CORS. La cadena de consulta obliga al navegador a no usar el recurso en caché.

Idealmente, cloudfront y S3 enviarían el encabezado Vary: Origin cuando CORS está habilitado y/o Webkit variaría implícitamente en el encabezado Origin, lo que supongo que hace Firefox ya que no tiene este problema.

6

definitivamente no es la mejor manera, pero podría deshabilitar el almacenamiento en caché de la solicitud de imagen agregando algún parámetro de URL a la solicitud. por lo general, esto se hace a través de JavaScript, por ejemplo:

var img = document.createElement('img'); 
img.setAttribute('src', yourRequestUrl + '?d=' + Date.now()); 
tagToAppendImg.appendChild(img); 

esto siempre va a forzar una respuesta sin caché, porque la fecha en milisegundos siempre produce una URL diferente que el navegador no lo sabe todavía, pero yo soy incierto si esto resuelve tu problema

0

Puede agregar la etiqueta img usando Javascript después de realizar su solicitud de CORS.

0

Una solución sería establecer el atributo crossorigin='use-credentials' en el img -tag para forzar al navegador que siempre haga una solicitud CORS, ver aquí: https://stackoverflow.com/a/34496683/725542

Otra solución sería configurando su distribución CloudFront para apagar automáticamente No- Solicitudes CORS en solicitudes CORS.Esto es posible al agregar un encabezado CORS a cada solicitud que CloudFront envía a S3 utilizando la función CloudFront agregada recientemente "Controlar los encabezados de las solicitudes Edge-To-Origin".

ver el anuncio función aquí: https://aws.amazon.com/blogs/aws/cloudfront-update-https-tls-v1-1v1-2-to-the-origin-addmodify-headers/

Y la documentación aquí: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html.

0

También encontré este problema. Terminé configurando una distribución frente a la nube frente a mi cubo S3 y establecí las opciones Origin Custom Headers en la sección Origin Settings en la nube para enviar Origin: https://example.com a mi origen S3. Esto hace que S3 sirva siempre los encabezados CORS, ya que siempre ve el encabezado de solicitud Origin. Para ello, debe asegurarse de que el encabezado Origin no esté incluido en la lista blanca por ninguno de sus comportamientos frente a la nube.

tl; dr: Le dije a la nube que envíe Origin: https://example.com con cada solicitud al origen de mi S3, y que sirvió mi contenido a través de la nube.

Cuestiones relacionadas