browser - falta - Efecto de caché en CORS: No hay encabezado ''Access-Control-Allow-Origin'' presente en el recurso solicitado

falta la cabecera cors ''access-control-allow-origin'' ajax (3)

Experimentamos el mismo problema al migrar nuestro JS a Webpack.

Nuestra configuración es similar:

los activos se cargan en un depósito S3 durante el despliegue
el depósito está configurado como el origen de Cloudfront

Al migrar a Webpack, queríamos aprovechar los mapas de origen de JS para reportar mejor los errores a Airbrake. Para permitir que los errores se capturen correctamente, el crossorigin="anonymous" debe establecerse en las etiquetas del script. La razón por la cual se explica aquí: https://blog.sentry.io/2016/05/17/what-is-script-error.html

Parte del problema era que los encabezados de respuesta CORS a veces se devolvían, a veces no, lo que desencadenaba un CORS errror en el navegador. Los servidores de Cloudfront almacenaban en caché la respuesta con O sin los encabezados de CORS, según la primera solicitud del cliente que realizara una solicitud de Miss.

Entonces dos posibles resultados:

El primer cliente no envía el encabezado de solicitud de origen => El servidor de Cloudfront almacena en caché la respuesta sin encabezados de CORS.
El primer cliente envía el encabezado de solicitud de origen => El servidor de Cloudfront almacena en caché la respuesta sin encabezados de CORS.

Esto hizo que el problema pareciera aleatorio, pero solo era una cuestión de condición de carrera (cómo el primer cliente hacía la solicitud) y diferentes encabezados almacenados en caché en diferentes servidores de Cloudfront: tiempo y ubicación dependientes. Agregue a eso el hecho de que los navegadores pueden almacenar en caché estos encabezados incorrectos ...

Por lo tanto, debe configurar correctamente el comportamiento de distribución de Cloudront para:

permitir y almacenar en caché las solicitudes de verificación previa (OPCIONES)
base la caché en los encabezados de solicitud CORS (Origen, Access-Control-Request-Headers, Access-Control-Request-Method)

Aquí está la configuración que resolvió nuestro problema.

Configuración de S3 bucket / Permissions / CORS:

<?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>*</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <AllowedMethod>HEAD</AllowedMethod> <MaxAgeSeconds>300</MaxAgeSeconds> <AllowedHeader>*</AllowedHeader> </CORSRule> </CORSConfiguration>

Distribución en la nube / Comportamiento de edición:

Ahora experimentamos un problema similar al suyo, ya que migramos nuestro CSS a Webpack. Estamos experimentando errores de CORS aún más esporádicos para los archivos CSS. Estamos intentando eliminar el crossorigin="anonymous" en las etiquetas <link rel="stylesheet" /> ya que no necesitamos el seguimiento de errores para los archivos CSS.

La versión corta de este problema es que estamos viendo el típico error CORS ( x has been blocked by CORS policy: No ''Access-Control-Allow-Origin'' header is present on the requested resource. ) x has been blocked by CORS policy: No ''Access-Control-Allow-Origin'' header is present on the requested resource. Sin embargo, estamos enviando absolutamente los encabezados especificados . Sin embargo, las solicitudes están bien para empezar después de n (patrón indeterminado) cantidad de tiempo ALGUNOS (no hay un patrón real en este otro que sea un azar 1 o 2 recursos referenciados en el archivo html) de pronto comenzarán a fallar. En una actualización difícil o con la desactivación de la caché, el problema se resuelve.

Nos preguntamos cómo el almacenamiento en caché puede afectar a CORS en este caso. O si el problema está en otra parte?

Lo que vemos es que el activo está bien cargado en primera instancia.

Aquí hay una representación cURL de lo que el navegador ( chrome , no probado en otro lugar) envía al servidor ( frente a la nube frente a s3 ):

curl -I ''https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css'' -H ''Referer: https://lystable.kalohq.ink/projects/2180?edit=true'' -H ''Origin: https://lystable.kalohq.ink'' -H ''DPR: 2'' -H ''User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gec

Y los encabezados en respuesta a esto se ven así:

HTTP/1.1 200 OK Content-Type: text/css Content-Length: 5632 Connection: keep-alive Date: Wed, 28 Jun 2017 09:23:04 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET Access-Control-Max-Age: 3000 Last-Modified: Wed, 28 Jun 2017 09:16:15 GMT ETag: "ece4babc2509d989254638493ff4c742" Cache-Control: max-age=31556926 Content-Encoding: gzip Accept-Ranges: bytes Server: AmazonS3 Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method Age: 3384 X-Cache: Hit from cloudfront Via: 1.1 adc13b6f5827d04caa2efba65479257c.cloudfront.net (CloudFront) X-Amz-Cf-Id: PcC2qL04aC4DPtNuwCudckVNM3QGhz4jiDL10IDkjIBnCOK3hxoMoQ==

Después de esto puede navegar por el sitio por un tiempo, actualizar algunas veces y todo está bien y elegante.

Pero luego puedes actualizar y de repente ves el error en la consola:

Access to CSS stylesheet at ''https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css'' from origin ''https://kalohq.ink'' has been blocked by CORS policy: No ''Access-Control-Allow-Origin'' header is present on the requested resource. Origin ''https://kalohq.ink'' is therefore not allowed access.

En este punto, si actualizas o deshabilitas la memoria caché y vuelves a cargar la página, todo volverá a funcionar. Es por eso que estamos señalando el comportamiento de caché del navegador jugando con CORS en este punto.

El archivo HTML que carga estos activos es el siguiente:

<!doctype html><html lang="en"><head><meta charset="utf-8"><meta http-equiv="X-UA-Compatible" content="IE=edge"><title>Kalo</title><meta name="description" content="Kalo is used by the best teams on the planet to onboard, manage, and pay their freelancers. "><meta name="viewport" content="width=device-width,initial-scale=1"><meta http-equiv="Accept-CH" content="Width,DPR,Save-Data"><script>window.performance&&"function"==typeof window.performance.mark&&window.performance.mark("start load bootstrap"),console.log("Kalo v0.214.1 🎉")</script><script type="text/javascript" crossorigin="anonymous">window.webpackManifest={0:"moment-timezone-data.8189aab661847dea1b73.chunk.js",1:"1.7645e36f0742ed31139b.chunk.js",2:"2.bf0a1c9b400d715e3138.chunk.js",3:"3.d077b7a1cede6f6960e6.chunk.js",4:"4.0bbd51f182d8fa3f4951.chunk.js",5:"5.1dcf124ea7874546fc7a.chunk.js",6:"6.85ee04326ef5cfe2c084.chunk.js",7:"7.cf718eabaa3814fcb47c.chunk.js",8:"8.4c4c5b070e09afe037a1.chunk.js",9:"9.ba3b9a5f540f057fca46.chunk.js",10:"10.3c850061770df8801575.chunk.js",11:"11.df971dd9c4ab435fd421.chunk.js",12:"12.81905afa591a4796dcfc.chunk.js",13:"13.0f78c0c77d45cd79ac26.chunk.js",14:"14.f8f9f24d15e1cc4372a1.chunk.js",15:"15.6badd92530b5da668e98.chunk.js",16:"16.ef87b8dc2f87ca2d40a1.chunk.js",17:"17.bf842b852470057c4f0b.chunk.js",18:"18.f091321e6a0bbf16bf1f.chunk.js",19:"19.0297861a162b49308887.chunk.js",20:"20.7281da4b01eb4eb4bf1f.chunk.js",21:"21.781ca5137a9c76031df2.chunk.js",22:"22.c7dfd45fc0bd41c7618d.chunk.js",23:"23.8c4885794fd57453884a.chunk.js",24:"24.1447090b6f41a311414e.chunk.js",25:"25.021a38e680888fe2ac7e.chunk.js",26:"26.1afe06be0d6164d3409a.chunk.js",27:"27.dc70b696039ad4762a3b.chunk.js",28:"28.8c383709ce92ecae6b0c.chunk.js",29:"29.f594eb538f606ae17c50.chunk.js",30:"30.a2c1dfc70e0fac57b2a4.chunk.js",31:"31.2eaee95b85227b23ccd8.chunk.js",32:"32.528e99c8151fef966483.chunk.js",33:"33.c3b7530ab92bc1280136.chunk.js",34:"34.1eb5635dc498ad450839.chunk.js",35:"35.e71c1e7bc6092ff2a35f.chunk.js",36:"36.0d174c67ddb177944140.chunk.js",37:"37.af1c6ed4cde9120da636.chunk.js",38:"38.fb0dd22a16e7b597ef93.chunk.js",39:"39.c17f705a3438de3dc997.chunk.js",40:"40.d509fa240e2adf2888aa.chunk.js",41:"41.37d2f0e0e06a3c7d816b.chunk.js",42:"42.4febbf78adc3084afec3.chunk.js",43:"43.7aa48b320fcf69adb0a3.chunk.js",44:"44.5e6da9391c7412910447.chunk.js",45:"45.a17d5b7c5e534f260841.chunk.js",46:"46.a1d3a7790959ac892ed0.chunk.js",47:"47.241627b0e5da4ce35606.chunk.js",48:"48.84f9532a64f5a3beb20c.chunk.js",49:"49.f8527afe7cade8fc293a.chunk.js",50:"50.776b466f9019479de8fc.chunk.js",51:"51.ca34827c84d4bcc82079.chunk.js",52:"52.517f4f6c63395646cdd7.chunk.js",53:"53.e3a2103e4151cd13300f.chunk.js",54:"athena.5e6c5b01662cea2c8b1a.chunk.js",55:"hera.b69b80db056ad9c9389f.chunk.js",56:"hermes.29bb236b97c128e8b6ee.chunk.js",57:"iris.834233a6fb064bf576a9.chunk.js",58:"hephaestus.7ac71b3274dda739ba1f.chunk.js",59:"59.ce1aefa687f2ef9c9908.chunk.js",60:"60.5070b818882287dfc402.chunk.js",61:"61.19d5149d0a2bd9ef3c1e.chunk.js",62:"62.d7831f900b939591822e.chunk.js"}</script><link rel="shortcut icon" href="https://assets-frontend.kalohq.ink/favicon.ico" crossorigin="anonymous"><link href="https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css" rel="stylesheet" crossorigin="anonymous"><link href="https://assets-frontend.kalohq.ink/style.hermes.689f9795642815d4b8afd20e446a174d.css" rel="stylesheet" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/hermes.29bb236b97c128e8b6ee.js" as="script" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/style.hermes.689f9795642815d4b8afd20e446a174d.css" as="style" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/allapps.commons.8395b1aa9666e3271c40.js" as="script" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css" as="style" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/vendor.83e606c69fc5ae7aeb9b.js" as="script" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/core/styles/fonts/Fakt-Soft-Pro-SemiBold/FaktSoftPro-SemiBold.1901bce5eea18c64a60693e961585ba1.woff" as="font" crossorigin="anonymous"><link rel="preload" href="https://assets-frontend.kalohq.ink/core/styles/fonts/Fakt-Soft-Pro-Blond/FaktSoftPro-Blond.4ab21e2be2f31a0ab8d798a9c65f99c1.woff" as="font" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/hera.b69b80db056ad9c9389f.js" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/iris.834233a6fb064bf576a9.js" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/athena.5e6c5b01662cea2c8b1a.js" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/moment-timezone-data.8189aab661847dea1b73.chunk.js" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/style.hera.f00a272db8e5756775fb2632e67c1056.css" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/style.iris.1465dc22f4279c748a04c66f3b4494de.css" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/style.athena.6acb14c0d060121364c9a0cf3e6fa0ad.css" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/_/node_modules/@kalo/ui/icon/fonts/MaterialIcons/MaterialIcons-Regular.012cf6a10129e2275d79d6adac7f3b02.woff" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/core/assets/fonts/MaterialIcons-Regular.012cf6a10129e2275d79d6adac7f3b02.woff" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/_/node_modules/@kalo/ui/icon/fonts/MaterialIcons/MaterialIcons-Regular.570eb83859dc23dd0eec423a49e147fe.woff2" crossorigin="anonymous"><link rel="prefetch" href="https://assets-frontend.kalohq.ink/core/assets/fonts/MaterialIcons-Regular.570eb83859dc23dd0eec423a49e147fe.woff2" crossorigin="anonymous"></head><body><main id="app"><noscript>Kalo - Work without boundaries Please wait a moment as we load Kalo. Please make sure you have Javascript enabled to continue. Kalo’s aim is to give companies complete visibility over their external network.</noscript><noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-5XLW75" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript></main><div class="root __splash"><style>html{position:static!important;overflow-y:auto}.root{transition:opacity .35s linear;color:#234957;background-color:#f9fafc;position:absolute;top:0;right:0;bottom:0;left:0;opacity:1}.root.exit{opacity:0!important}.navigation{height:60px;background:#fff;border-bottom:1px solid #eceff1}.login{background:#ea5f6e;position:absolute;top:0;left:0;bottom:0;width:50%;display:flex;justify-content:center;align-items:center}@media screen and (max-width:767px){.login{width:100%;right:0}}.hide{display:none!important}.logo{height:107px}</style><div id="navbar" class="navigation hide"></div><div id="login" class="login hide"><div class="logo"><svg width="160" height="70" viewBox="0 0 206 90" xmlns="http://www.w3.org/2000/svg"><title>Kalo</title><path fill-rule="evenodd" fill="#fff" d="M17.629 47.172c2.31 0 4.254-.986 6.078-2.833l18.845-19.706c1.824-1.971 3.89-2.957 6.323-2.957 7.294 0 10.212 9.114 5.835 13.55L35.378 54.562l18.724 19.706c3.283 3.571 3.526 8.498.244 12.07-1.46 1.601-3.406 2.464-5.837 2.464-2.552 0-4.62-.986-6.2-2.834L23.707 65.646c-1.7-1.847-3.647-2.832-5.835-2.832h-1.58v17.612c0 4.804-3.405 8.5-8.147 8.5-4.376 0-8.145-3.942-8.145-8.5V8.498C0 3.695 3.647 0 8.145 0c4.5 0 8.147 3.695 8.147 8.498v38.674h1.337zm97.134 29.56c0 2.586-.972 4.433-2.916 5.789-6.566 4.557-15.077 6.773-25.654 6.773-16.656 0-25.653-9.236-25.653-21.676 0-11.455 8.146-20.076 25.045-20.076 3.891 0 8.39.616 13.496 1.848v-3.326c0-6.528-3.283-9.608-11.55-9.608-3.525 0-7.417.74-11.672 2.095-6.686 2.094-11.185-1.11-11.185-6.405 0-3.572 1.823-6.035 5.35-7.513 4.742-2.094 10.698-3.08 17.871-3.08 17.872 0 26.868 8.376 26.868 25.003v30.176zm-15.682-4.68V60.965c-4.378-1.354-8.39-1.97-12.159-1.97-6.443 0-10.577 3.202-10.577 8.006 0 5.296 4.134 8.252 10.942 8.252 4.5 0 8.51-1.11 11.794-3.203zm39.845 8.904c0 4.803-3.405 8.498-8.147 8.498-4.376 0-8.145-3.941-8.145-8.498V9.15c0-4.803 3.647-8.62 8.145-8.62 4.5 0 8.147 3.817 8.147 8.62v71.806zm57.513 1.359c-5.348 4.681-12.035 7.02-20.06 7.02-7.903 0-14.589-2.339-20.06-7.02-5.471-4.68-8.511-10.715-9.118-17.982-.365-5.788-.365-11.7 0-17.612.607-7.391 3.525-13.426 8.996-18.106 5.472-4.68 12.28-7.02 20.183-7.02 8.024 0 14.71 2.34 20.06 7.02 5.349 4.68 8.389 10.715 8.997 18.106.365 5.789.365 11.7 0 17.488-.608 7.391-3.648 13.427-8.998 18.106zm-7.172-33.009c-.363-7.02-5.229-11.946-12.887-11.946-7.417 0-12.402 4.68-13.01 11.946a69.483 69.483 0 0 0 0 12.318c.608 7.266 5.593 11.946 13.01 11.946 7.416 0 12.4-4.68 12.887-11.946a69.326 69.326 0 0 0 0-12.318z"/></svg></div></div><script>"/login"===window.location.pathname&&-1===document.cookie.indexOf("VIEW=")?document.getElementById("login").classList.remove("hide"):document.getElementById("navbar").classList.remove("hide"),document.querySelector(".__splash.root").id="splash"</script></div><script src="https://cdn.polyfill.io/v2/polyfill.min.js?features=Symbol,fetch,Intl.~locale.en&unknown=polyfill"></script><script src="https://apis.google.com/js/client.js" async></script><script src="https://maps.googleapis.com/maps/api/js?key=AIzaSyDteWPK1-k97egIjYcX8-Btt8SpRsHit50&libraries=places" async></script><script>!function(e,t,a,n,c,o,s){e.GoogleAnalyticsObject=c,e[c]=e[c]||function(){(e[c].q=e[c].q||[]).push(arguments)},e[c].l=1*new Date,o=t.createElement(a),s=t.getElementsByTagName(a)[0],o.async=1,o.src="https://www.google-analytics.com/analytics.js",s.parentNode.insertBefore(o,s)}(window,document,"script",0,"ga"),ga("create","","auto")</script><script>!function(e,t,a,n,g){e[n]=e[n]||[],e[n].push({"gtm.start":(new Date).getTime(),event:"gtm.js"});var m=t.getElementsByTagName(a)[0],r=t.createElement(a);r.async=!0,r.src="https://www.googletagmanager.com/gtm.js?id=GTM-5XLW75",m.parentNode.insertBefore(r,m)}(window,document,"script","dataLayer")</script><script>!function(){function t(){var t=a.createElement("script");t.type="text/javascript",t.async=!0,t.src="https://widget.intercom.io/widget/s21m3m5m";var e=a.getElementsByTagName("script")[0];e.parentNode.insertBefore(t,e)}var e=window,n=e.Intercom;if("function"==typeof n)n("reattach_activator"),n("update",intercomSettings);else{var a=document,c=function(){c.c(arguments)};c.q=[],c.c=function(t){c.q.push(t)},e.Intercom=c,e.attachEvent?e.attachEvent("onload",t):e.addEventListener("load",t,!1)}}()</script><script type="text/javascript" src="https://assets-frontend.kalohq.ink/vendor.83e606c69fc5ae7aeb9b.js" crossorigin="anonymous"></script><script type="text/javascript" src="https://assets-frontend.kalohq.ink/allapps.commons.8395b1aa9666e3271c40.js" crossorigin="anonymous"></script><script type="text/javascript" src="https://assets-frontend.kalohq.ink/hermes.29bb236b97c128e8b6ee.js" crossorigin="anonymous"></script></body></html>

Algo a tener en cuenta aquí es que todas las etiquetas de script y de link tienen crossorigin="anonymous" . También tenga en cuenta las etiquetas de precarga y captación previa.

El problema es que afecta principalmente a las hojas de estilo, pero PERO las secuencias de comandos también se han visto afectadas de la misma manera. De nuevo, es realmente extraño que parezca elegir aleatoriamente qué activos se romperán y cuándo. Teniendo en cuenta estos dos hechos, tal vez incluso se base en el orden de referencia en la orden de documento / carga.

Algunas aclaraciones finales con suerte para ayudar:

Activos servidos desde la nube frente a s3 (ver encabezados de respuesta)
No he tenido informes / pruebas en buscadores que no sean Chrome en este punto, aunque espero poder actualizarlo en breve
Todos los recursos de script y de hoja de estilo se precargan con

Cualquier ayuda u orientación con este tema va a ser muy apreciada. ¡Está bastante bloqueado en este momento!

Actualizar:

Así que hemos logrado obtener lo que parece ser una construcción en continuo funcionamiento sin ningún problema aparente. Difícil de saber por 100% sin tiempo debido a la naturaleza aparentemente esporádica / aleatoria del problema. Lo que cambiamos fue lo siguiente:

Omitir Cloudfront para referenciar directamente los activos en S3. ¿Qué podría ser diferente?
Establezca access-control-max-age en -1 que deshabilita esto. No esperaríamos que esto tenga ningún efecto porque esto solo debería (lectura de especificaciones) afectar las solicitudes de verificación previa que no ocurren para las solicitudes GET.
Elimine las etiquetas de enlace de precarga / búsqueda previa.

Ahora estamos haciendo más pruebas para tratar de aislar a uno o a un combo de estos como culpables. Luego podemos profundizar en lo que está sucediendo allí.

Tenga en cuenta que resolver este problema ahora se ha demostrado incorrecto. Ver actualización 2 .

Actualización 2:

Hemos tenido más informes y ocurrencias internos del problema después del lanzamiento anterior, que pensamos que eludimos el problema. Uno de los efectos del lanzamiento anterior fue que ahora el problema se ve con mucha menos frecuencia. De nuevo, una actualización fuerte corrige todo.

El problema es idéntico al descrito anteriormente y, hasta el momento, no hemos visto de primera mano una falla al cargar JS desde la primera vez que ocurre, siempre parece ser un archivo CSS que falla ahora.

Actualización 3:

Alguna información bastante importante que no mencioné originalmente es el cambio que sucedió alrededor del momento en que este problema comenzó a presentarse.

El lunes pasado lanzamos un refactor de paquetes, con tecnología de webpack que significaba que los activos se compartían entre las implementaciones. Por ejemplo, si un archivo de salida allapps.commons.HASH123.css no cambió entre las versiones v1 y v2, la idea es que podamos aprovechar el almacenamiento en caché del navegador.

Sin embargo, lo que todavía sucede es que el script que carga estos activos a S3 está subiendo y anulando en vano el archivo original. Estábamos bajo la suposición de que este cambio sería bastante inofensivo ya que el archivo tiene el mismo nombre y contenido, pero quizás esto tenga algún efecto adverso.

Otro efecto de este lanzamiento fue que ahora habrá muchos más activos debido a la división de código agresiva. Una cosa a tener en cuenta aquí es que ninguno de los fragmentos asíncronos parece sufrir el mismo problema (están usando jsonp después de todo) y el problema es solo con la referencia de los activos a través de las etiquetas <script> y <link> .

Puede encontrar los artefactos de construcción de la publicación ANTES del lanzamiento de interrupción here . Y encuentre los NUEVOS artefactos de construcción de la versión activa actual que muestran problemas infrecuentes here . También puede encontrar nuestros scripts de implementación here

Todos los recursos se pueden encontrar en Google Drive here .

Actualización 4:

Este problema todavía está ocurriendo y ahora se ha informado sobre un fragmento asíncrono que se carga a petición. Al observar el tiempo de ejecución de la carpeta web, estos scripts se cargan al agregar una nueva etiqueta de script a la página, nuevamente con crossorigin="anonymous" .

Actualización 5:

En cada compilación, ahora usamos una sal única (la versión de lanzamiento) al mezclar los nombres de los archivos. Esto significa que no se comparten activos entre compilaciones. El problema persiste después de este lanzamiento.

Actualización 6:

.har un archivo .har que muestra este problema durante una sesión de usuario.

Busque la siguiente "url": "https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css", cadena "url": "https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css", y vea las diversas solicitudes realizadas para este activo. Verá que los primeros están bien y tienen los encabezados que espera. La última ocurrencia (línea 32624) es la que falló.

{ "startedDateTime": "2017-06-28T09:40:15.534Z", "time": 0, "request": { "method": "GET", "url": "https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css", "httpVersion": "unknown", "headers": [ { "name": "Referer", "value": "https://kalohq.ink/account" }, { "name": "Origin", "value": "https://kalohq.ink" }, { "name": "DPR", "value": "2" }, { "name": "User-Agent", "value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" } ], "queryString": [], "cookies": [], "headersSize": -1, "bodySize": 0 }, "response": { "status": 0, "statusText": "", "httpVersion": "unknown", "headers": [], "cookies": [], "content": { "size": 0, "mimeType": "x-unknown" }, "redirectURL": "", "headersSize": -1, "bodySize": -1, "_transferSize": 0, "_error": "" }, "cache": {}, "timings": { "blocked": -1, "dns": -1, "connect": -1, "send": 0, "wait": 0, "receive": 0, "ssl": -1 }, "serverIPAddress": "", "pageref": "page_10" },

Actualización 7:

Así que anoche presionamos un cambio que eliminó el uso del crossorigin="anonymous" todas partes . Hasta ahora no hemos visto el problema (todavía estamos esperando dada la naturaleza del problema) pero estamos viendo respuestas interesantes e inesperadas de las solicitudes que se están realizando ahora. Sería genial si pudiéramos obtener una aclaración sobre qué es exactamente lo que está sucediendo aquí. No creo que crossorigin="anonymous" eliminar crossorigin="anonymous" para tener tal efecto o incluso entender por qué estaba tan roto antes, ya que nuestro servidor está configurado para enviar los encabezados correctos Y el encabezado Vary .

Solicitud de cli a s3, con un encabezado Origin, sin encabezados de respuesta cors

curl -I ''https://s3.amazonaws.com/olympus.lystable.com/style.allapps.5ebcc4d28ec238a53f46d6c8e12900d1.css'' -H ''Pragma: no-cache'' -H ''Accept-Encoding: gzip, deflate, br'' -H ''Accept-Language: en-GB,en-US;q=0.8,en;q=0.6'' -H ''User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/59.0.3071.109 Chrome/59.0.3071.109 Safari/537.36'' -H ''Accept: text/css,*/*;q=0.1'' -H ''Referer: https://asos.kalohq.com/categories'' -H ''Connection: keep-alive'' -H ''DPR: 1'' -H ''Cache-Control: no-cache'' -H "Origin: https://kalohq.com" --compressed HTTP/1.1 200 OK x-amz-id-2: kxOvBrYsKyZ42wGgJu8iyRZ8q6j5DHDC6QoK1xn2e8FO1wIEEVkxQ0JvGQTmwrN/Njf8EOlmLrE= x-amz-request-id: DA8B5488D3A7EF73 Date: Thu, 13 Jul 2017 13:27:47 GMT Last-Modified: Thu, 13 Jul 2017 11:30:50 GMT ETag: "c765a0a215cb4c9a074f22c3863c1223" Cache-Control: max-age=31556926 Content-Encoding: gzip Accept-Ranges: bytes Content-Type: text/css Content-Length: 5887 Server: AmazonS3

Solicite un momento más tarde de cli nuevamente a s3 con solo encabezado de origen. Ahora de repente devuelve todos los encabezados de cors esperados ...

curl -H "Origin: https://kalohq.com" -I https://assets-frontend.kalohq.com/style.allapps.5ebcc4d28ec238a53f46d6c8e12900d1.css HTTP/1.1 200 OK Content-Type: text/css Content-Length: 5887 Connection: keep-alive Date: Thu, 13 Jul 2017 13:33:09 GMT Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET Access-Control-Max-Age: -1 Last-Modified: Thu, 13 Jul 2017 11:30:50 GMT ETag: "c765a0a215cb4c9a074f22c3863c1223" Cache-Control: max-age=31556926 Content-Encoding: gzip Accept-Ranges: bytes Server: AmazonS3 Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method Age: 69 X-Cache: Hit from cloudfront Via: 1.1 a19c66da9b402e0bee3fd29619661850.cloudfront.net (CloudFront) X-Amz-Cf-Id: 3wQ7Z6EaAcMscGirwsYVi1M_rvoc1fbI034QY4QZd6IqmlRzLRllEg==

Actualización 8:

La eliminación de las crossorigin="anonymous" ha resuelto el problema. La investigación sobre por qué esto repentinamente comenzó a ser un problema con este lanzamiento está en curso ya que antes teníamos este atributo en las etiquetas de script.

Todos los recursos útiles en esta investigación se pueden encontrar en Google Drive here .

Puedo arrojar algo de luz sobre cómo sucedió con nosotros. Azure CDN (que usamos) no es compatible con Vary: encabezados en este momento. Hasta ahora, tan malo. Pero ahora usamos el atributo script crossorigin que, y eso es lo interesante, no es compatible con algunos navegadores.

Si ahora ese navegador llega a nuestro sitio, no envía origen: porque no comprende el atributo "crossorigin". Si luego viene otro que lo entiende, enviará el origen: -> CORS Error porque la primera respuesta está en caché.

Feo.

https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css solo devuelve encabezados CORS cuando hay un encabezado "Origen" presente (que se envía con una solicitud CORS, pero no solicitudes regulares).

Esto es lo que sucede:

El usuario obtiene CSS como parte de una solicitud sin CORS (por ejemplo, <link rel="stylesheet"> ). Esto se almacena en caché debido al encabezado Cache-Control .
El usuario obtiene CSS como parte de una solicitud CORS. La respuesta proviene del caché.
La comprobación CORS falla, no hay encabezado Access-Control-Allow-Origin .

El servidor tiene la culpa aquí, debe usar el encabezado Vary para indicar sus cambios de respuesta dependiendo del encabezado de Origin (y otros). Envía este encabezado en respuesta a las solicitudes CORS, pero también debe enviarlo en respuesta a solicitudes que no sean CORS.

En este caso, Chrome tiene alguna falla, ya que debe usar el modo de credenciales de la solicitud como parte de la clave de almacenamiento en caché, por lo que una solicitud sin credenciales (como las enviadas por fetch() ) no debe coincidir con los elementos del caché que solicitado con credenciales. Creo que hay otros navegadores que se comportan como Chrome aquí, pero Firefox no.

Sin embargo, dado que está utilizando un CDN, no puede confiar en los navegadores para hacerlo bien, ya que el almacenamiento en caché aún puede ocurrir en el CDN. Agregar el encabezado Vary correcto es la solución correcta.

tl; dr: agregue el siguiente encabezado a todas sus respuestas que admiten CORS:

Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method