caching - headers - cors header ‘access-control-allow-origin’ missing

La respuesta en caché no CORS entra en conflicto con la nueva solicitud CORS

Question

Esencia:

Tengo una página que usa la carga de etiquetas de una imagen de s3 (etiqueta HTML img ) y tengo una página que usa xmlhttprequest . La carga de etiqueta se almacena en caché sin los encabezados CORS y, por lo tanto, xmlhttprequest ve la versión almacenada en caché, comprueba sus encabezados y falla con un error de origen cruzado.

Detalles:

editar : falla en safari 5.1.6 y en cromo 21.0.1180.89. Funciona bien en Firefox 14.

Usando los nuevos CORS de S3, configuro una CORSRule manera:

<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 los encabezados de solicitud, obtengo la imagen sin encabezados CORS en la respuesta.

Esto se almacena en caché y las solicitudes subsiguientes de CORS (una que establece el origen en el encabezado de la solicitud) se rechazan 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é? ¿Debería diferenciar las solicitudes CORS al ?some_flag 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".

Answer 1

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. generalmente, 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 forzará una respuesta no almacenada, porque la fecha en milisegundos siempre produce una URL diferente que el navegador aún no conoce, pero no estoy seguro si esto resuelve su problema.

Answer 2

Me encontré con este problema, también. Terminé configurando una distribución frente a la nube frente a mi cubo S3 y establecí las opciones de 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 de Origin . Para hacerlo, debes asegurarte de que el encabezado Origin no esté incluido en la lista blanca por ninguno de tus comportamientos frente a la nube.

tl; dr: Le dije a cloudfront que enviara Origin: https://example.com con cada solicitud a mi origen S3 y que entregara mi contenido a través de la nube.

Answer 3

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

Answer 4

Tuve 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 de Origin, lo que supongo que hace Firefox ya que no tiene este problema.

Answer 5

Una solución sería establecer el crossorigin=''use-credentials'' en el img -tag para obligar al navegador a realizar siempre una solicitud CORS, consulte aquí: https://.com/a/34496683/725542

Otra solución sería configurar su distribución CloudFront para convertir automáticamente las solicitudes que no son 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".

Vea el anuncio de 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 .