Effet de mise en cache sur CORS: aucun en-tête «Access-Control-Allow-Origin» n'est présent sur la ressource demandée
La version courte de ce problème est que nous voyons l'erreur CORS typique (x has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.) mais nous envoyons absolument les en-têtes spécifiés. Les demandes sont bien pour commencer cependant après un temps n (modèle indéterminé) CERTAINES (pas de modèle réel à cela autre que c'est un ou deux actifs aléatoires référencés dans le fichier html) les demandes commenceront soudainement à échouer. Lors d'une actualisation matérielle ou en désactivant le cache, le problème est résolu.
Nous nous demandons comment la mise en cache peut affecter CORS dans ce cas? Ou si le problème se situe ailleurs?
Ce que nous voyons, c'est que l'actif est bien chargé en premier lieu.
Voici une représentation cURL de ce que le navigateur ( chrome , non testé ailleurs) envoie au serveur ( cloudfront en face de 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
Et les en-têtes en réponse à cela ressemblent à:
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==
Après cela, vous pouvez parcourir le site pendant un certain temps, rafraîchir plusieurs fois et tout va bien et dandy.
Mais alors vous pourriez rafraîchir et soudain vous voyez l'erreur dans la console:
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.
À ce stade, si vous actualisez ou désactivez le cache et rechargez la page, tout recommence à fonctionner. C'est pourquoi nous pointons le comportement de mise en cache du navigateur jouant avec CORS à ce stade.
Le fichier HTML qui charge ces ressources est le suivant:
<!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"><!--[if lt IE 8]>
<p class="browserupgrade">You are using an outdated browser. Please <a href="http://browsehappy.com/">upgrade your browser</a> to improve your experience.</p>
<![endif]--><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>
Il convient de noter ici que toutes les balises script et link ont crossorigin="anonymous". Notez également les balises de préchargement et de prélecture.
Le problème affecte principalement les feuilles de style, il semble que les scripts MAIS ont également été affectés de la même manière. Encore une fois, il est vraiment étrange qu'il semble choisir au hasard quels actifs se briseront et quand. Compte tenu de ces deux faits, il est peut-être même basé sur l'ordre de référence dans le document/ordre de chargement.
Quelques clarifications finales, espérons-le, pour vous aider:
- Actifs servis à partir de cloudfront en face de s3 (voir en-têtes de réponse)
- Pas eu de rapports/tests dans des navigateurs autres que chrome à ce stade, mais nous espérons pouvoir le mettre à jour sous peu
- Tous les actifs de script et de feuille de style sont préchargés à l'aide de
Toute aide ou conseil concernant ce problème sera grandement apprécié. C'est assez bloquant pour le moment!
Mise à jour:
Nous avons donc réussi à obtenir ce qui semble être une construction en fonctionnement continu sans aucun problème apparent. Difficile à savoir à 100% sans temps en raison de la nature apparemment sporadique/aléatoire du problème. Ce que nous avons changé était le suivant:
- Contournez Cloudfront pour référencer directement les actifs dans S3. Qu'est-ce qui pourrait être différent?
- Ensemble
access-control-max-ageà-1ce qui le désactive. Nous ne nous attendons pas à ce que cela ait un effet, car cela ne devrait (lecture des spécifications) qu'affecter les requêtes de contrôle en amont qui ne se produisent pas pour les requêtes GET. - Supprimez les balises de lien de préchargement/prélecture.
Nous faisons maintenant d'autres tests pour essayer d'isoler un ou un combo de ceux-ci en tant que coupables. Nous pouvons ensuite approfondir ce qui s'y passe.
Notez ceci résolution le problème a maintenant été prouvé incorrect. Voir Update 2.
Mise à jour 2:
Nous avons eu d'autres rapports et incidents en interne sur le problème après le déploiement précédent qui, à notre avis, a contourné le problème. L'un des effets du déploiement précédent a été que le problème est désormais beaucoup moins fréquent. Encore une fois, une actualisation matérielle corrige tout.
Le problème est identique à celui décrit précédemment et jusqu'à présent, nous n'avons pas vu de première main un échec de chargement de JS depuis la première occurrence - semble toujours être un fichier CSS qui échoue maintenant.
Mise à jour 3:
Certaines informations assez importantes que je n'ai pas mentionnées à l'origine sont le changement qui s'est produit au moment où ce problème a commencé à se présenter.
Lundi dernier, nous avons publié un refactor bundle, alimenté par webpack , ce qui signifie que les actifs sont partagés entre les déploiements. Par exemple, si un fichier de sortie allapps.commons.HASH123.css n'a pas changé entre les versions v1 et v2, l'idée est que nous pourrions tirer parti de la mise en cache du navigateur.
Ce qui se passe cependant, c'est que le script téléchargeant ces ressources vers S3 [~ # ~] est [~ # ~] actuellement en train de télécharger et de remplacer le fichier d'origine. Nous étions dans l'hypothèse que ce changement serait assez inoffensif car le fichier a le même nom et le même contenu, mais cela a peut-être un effet négatif?
Un autre effet de cette version a été qu'il y aura désormais beaucoup plus d'actifs en raison de l'agressivité fractionnement de code . Cependant, une chose à noter ici est qu'aucun des morceaux asynchrones ne semble souffrir du même problème (ils utilisent après tout jsonp) et le problème ne concerne que ces références d'actifs via <script> et <link> Mots clés.
Vous pouvez trouver les artefacts de build de la version AVANT la version de rupture ici . Et trouvez les NOUVEAUX artefacts de construction de la version active actuelle montrant des problèmes peu fréquents ici . Vous pouvez également trouver nos scripts de déploiement ici
Toutes les ressources peuvent être trouvées sur Google Drive ici .
Mise à jour 4:
Ce problème persiste et a maintenant été signalé sur un bloc asynchrone chargé à la demande. En regardant le runtime du webpack, ces scripts sont chargés en ajoutant une nouvelle balise de script à la page, à nouveau avec crossorigin="anonymous".
Mise à jour 5:
Sur chaque build, nous utilisons maintenant un sel unique (la version finale) lors du hachage des noms de fichiers. Cela signifie qu'aucun actif n'est partagé entre les générations. Le problème a continué de persister après cette version.
Mise à jour 6:
J'ai téléchargé un .har file montrant ce problème survenant au cours d'une session utilisateur.
Recherchez la chaîne suivante "url": "https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css", et consultez les différentes demandes de cet actif. Vous verrez que les premiers sont corrects et auront les en-têtes que vous attendez. La dernière occurrence (ligne 32624) est celle qui a échoué.
{
"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"
},
Mise à jour 7:
Hier soir, nous avons donc proposé un changement qui a supprimé l'utilisation du crossorigin="anonymous" attribut partout. Jusqu'à présent, nous n'avons pas vu le problème se produire (toujours en attente étant donné la nature du problème), mais nous voyons des réponses intéressantes et inattendues des demandes en cours. Ce serait formidable si nous pouvions obtenir des éclaircissements sur ce qui se passe exactement ici. Je ne pense pas que nous nous attendions à supprimer crossorigin="anonymous" pour avoir un tel effet ou même comprendre pourquoi il était si cassé auparavant puisque notre serveur est configuré pour envoyer les en-têtes corrects ET l'en-tête Vary.
Demande de cli à s3, avec un en-tête Origin, pas d'en-têtes de réponse 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
Demander un instant plus tard de cli à s3 avec juste l'en-tête Origin. Rend maintenant soudainement tous les en-têtes cors attendus ...
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==
Mise à jour 8:
La suppression de crossorigin="anonymous" les balises ont résolu le problème. L'enquête pour savoir pourquoi cela a soudainement commencé à poser problème avec cette version est en cours, car nous avions cet attribut sur les balises de script avant.
Toutes les ressources utiles dans cette enquête se trouvent sur Google Drive ici .
https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css renvoie uniquement les en-têtes CORS lorsqu'un en-tête "Origin" est présent (qui est envoyé avec une demande CORS, mais pas régulier) demandes).
Voici ce qui se passe:
- L'utilisateur récupère CSS dans le cadre d'une demande sans CORS (par exemple,
<link rel="stylesheet">). Cela se cache en raison de l'en-têteCache-Control. - L'utilisateur récupère CSS dans le cadre d'une demande CORS. La réponse vient du cache.
- La vérification CORS échoue, aucun en-tête
Access-Control-Allow-Origin.
Le serveur est en faute ici, il doit utiliser l'en-tête Vary pour indiquer ses changements de réponse en fonction de l'en-tête Origin (et autres). Il envoie cet en-tête en réponse aux demandes CORS, mais il doit également l'envoyer en réponse aux demandes non CORS.
Chrome est quelque peu en faute ici, car il devrait utiliser le mode d'informations d'identification de la demande dans le cadre de la clé de mise en cache, de sorte qu'une demande sans informations d'identification (telles que celles envoyées par fetch()) ne devrait pas correspondre aux éléments de le cache demandé avec les informations d'identification. Je pense qu'il existe d'autres navigateurs qui se comportent comme Chrome ici, mais pas Firefox.
Cependant, puisque vous utilisez un CDN, vous ne pouvez pas compter sur les navigateurs pour faire les choses correctement, car la mise en cache peut toujours se produire sur le CDN. L'ajout de l'en-tête Vary correct est la bonne solution.
tl; dr: ajoutez l'en-tête suivant à toutes vos réponses qui prennent en charge CORS:
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Nous avons rencontré le même problème lors de la migration de notre JS vers Webpack.
Notre configuration est similaire:
- les actifs sont téléchargés dans un compartiment S3 pendant le déploiement
- le compartiment est défini comme l'origine de Cloudfront
Lors de la migration vers Webpack, nous voulions profiter des sourcemaps JS pour un meilleur rapport d'erreurs à Airbrake. Pour permettre aux erreurs d'être correctement détectées, le crossorigin="anonymous" l'attribut devait être défini sur les balises de script. La raison pour laquelle est expliquée ici: https://blog.sentry.io/2016/05/17/what-is-script-error.html
Une partie du problème était que les en-têtes de réponse CORS étaient parfois retournés, parfois non, déclenchant une erreur CORS dans le navigateur. Les serveurs Cloudfront mettaient en cache la réponse avec OR sans les en-têtes CORS, selon la première demande client faisant une demande Miss.
Donc, deux résultats possibles:
- Le premier client n'envoie pas l'en-tête de demande d'origine => le serveur Cloudfront met en cache la réponse sans en-têtes CORS.
- Le premier client envoie l'en-tête de demande d'origine => le serveur Cloudfront met en cache la réponse sans en-têtes CORS.
Cela a donné l'impression que le problème était aléatoire, mais c'était simplement une question de concurrence (comment le premier client a fait la demande) et de différents en-têtes mis en cache sur différents serveurs Cloudfront: le moment et l'emplacement dépendent. Ajoutez à cela le fait que les navigateurs peuvent mettre en cache ces mauvais en-têtes ...
Vous devez donc configurer correctement le comportement de distribution de Cloudront pour:
- autoriser et mettre en cache les demandes de contrôle en amont (OPTIONS)
- baser le cache sur les en-têtes de demande CORS (Origin, Access-Control-Request-Headers, Access-Control-Request-Method)
Voici la configuration qui a résolu notre problème.
Seau S3/Autorisations/Configuration 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>
Distribution Cloudfront/Comportement d'édition:
Nous rencontrons maintenant un problème similaire au vôtre, car nous venons de migrer notre CSS vers Webpack. Nous rencontrons encore plus d'erreurs CORS sporadiques pour les fichiers CSS. Nous essayons de supprimer le crossorigin="anonymous" attribut sur <link rel="stylesheet" /> tags car nous n'avons pas besoin du suivi des erreurs pour les fichiers CSS.
Je peux éclairer un peu comment cela s'est passé avec nous. Azure CDN (que nous utilisons) ne prend pas en charge les en-têtes Vary: pour le moment. Jusqu'ici tout va mal. Mais maintenant, nous utilisons l'attribut script crossorigin qui - et c'est la chose intéressante - n'est pas pris en charge par certains navigateurs.
Si maintenant un tel navigateur arrive sur notre site, il n'envoie pas Origin: car il ne comprend pas l'attribut "crossorigin". Si plus tard un autre vient qui le comprend, il enverra Origin: -> CORS Error car la première réponse est mise en cache.
Laid.