107 votes

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 assistons à l'typiques de la SCRO erreur (x has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.) cependant, nous sommes absolument d'envoi spécifié en-têtes. Les demandes sont très bien pour commencer mais après n (schéma indéterminée) quantité de temps que CERTAINS (pas de motif réel de ce que d'autres que c'est un hasard 1 ou 2 actifs référencés dans le fichier html) les demandes va soudainement commencer à défaut. Sur un rafraîchissement ou avec la désactivation du cache, le problème est résolu.

Nous nous demandons comment la mise en cache peut affecter la SCRO dans ce cas? Ou si le problème est ailleurs?

Ce que nous voyons est l'actif est chargé d'amende en première instance.

Voici une boucle de la représentation de ce que le navigateur (chrome, pas testé ailleurs) envoie au serveur (cloudfront devant 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 de réponse à cette apparence:

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 naviguer sur le site pendant un certain temps, actualiser un peu de temps et tout va bien dans le meilleur des mondes.

Mais alors vous pourrez vous rafraîchir et tout à coup 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-actualiser ou de désactiver le cache et de recharger la page, tout redevient de travail. C'est pourquoi nous les signaler à la mise en cache du navigateur comportement de jouer avec de la SCRO à ce point.

Le fichier HTML de chargement de ces actifs sont comme suit:

<!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 

52voto

Jaffa The Cake Points 1353

https://assets-frontend.kalohq.ink/style.allapps.add899080acbbeed5bb6a7301d234b65.css seuls les retours de la SCRO-têtes lorsqu'une "Origine" de l'en-tête est présent (ce qui est envoyé avec un SCRO demande, mais pas de demandes régulières).

Voici ce qui arrive:

  1. L'utilisateur récupère CSS dans le cadre d'une non-SCRO demande (par exemple, <link rel="stylesheet">). Cette caches en raison de l' Cache-Control - tête.
  2. L'utilisateur récupère CSS dans le cadre de la SCRO demande. La réponse vient de la cache.
  3. La SCRO vérification échoue, n' Access-Control-Allow-Origin - tête.

Le serveur est en faute, il doit utiliser l' Vary - tête pour indiquer sa réponse en fonction des changements de l' Origin - tête (et les autres). Il envoie cet en-tête en réponse à la SCRO les demandes, mais il doit l'envoyer en réponse à la non-SCRO demandes trop.

Le Chrome est un peu en faute, comme il se doit d'utiliser les informations d'identification de mode de la demande dans le cadre de la mise en cache de clé, de sorte qu'un non-accrédités demande (tels que ceux envoyés par fetch()) ne devrait pas correspondre à des éléments dans le cache qui a été demandé avec des informations d'identification. Je pense qu'il y a d'autres navigateurs qui se comportent comme Chrome ici, mais Firefox ne fonctionne pas.

Cependant, puisque vous êtes en utilisant un CDN, vous ne pouvez pas compter sur les navigateurs pour obtenir ce droit, comme la mise en cache peut encore arriver à la CAN. Ajout de la bonne Vary - tête est la solution adéquate.

tl;dr: Ajouter l'en-tête suivant à tous de vos réponses qui prennent en charge les catégories de documents:

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

12voto

lakim Points 308

Nous avons connu le même problème lors de la migration de notre JS pour Webpack.

Notre configuration est similaire:

  • les actifs sont transférés à un compartiment S3 cours de déploiement
  • le seau est définie comme l'origine Cloudfront

Lors de la migration vers Webpack, nous avons voulu profiter de la JS sourcemaps pour le meilleur rapport d'erreurs de frein pneumatique. Pour permettre aux erreurs de maîtriser correctement, l' crossorigin="anonymous" attribut a dû être mis sur les balises de script. La raison en est expliqué ici: https://blog.sentry.io/2016/05/17/what-is-script-error.html

Une partie du problème est que la SCRO en-têtes de réponse ont été renvoyée parfois, parfois pas, déclenchement de la SCRO erreur dans le navigateur. Cloudfront serveurs de mise en cache la réponse avec OU sans la SCRO en-têtes, selon la première requête du client de faire un Miss demande.

De sorte que deux résultats possibles:

  1. Premier client n'envoie pas l'Origine de la demande d'en-tête => Cloudfront serveur met en cache la réponse sans la SCRO en-têtes.
  2. Premier client envoie la requête d'Origine de l'en-tête => Cloudfront serveur met en cache la réponse sans la SCRO en-têtes.

De ce fait le problème de ressembler à elle a été faite au hasard, mais c'était juste une question de "race condition" (comment le premier client en fait la demande) et les différents en-têtes de cache sur les différents Cloudfront serveurs: le calendrier et la localisation de la dépendance. Ajoutez à cela le fait que les navigateurs peuvent cache ces mauvaises têtes...

Donc, vous avez besoin pour configurer correctement Cloudront de distribution du comportement:

  • permettre et cache de contrôle en amont (OPTIONS) les demandes
  • la base de la cache sur la SCRO-têtes de la requête (Origine, de Contrôle d'Accès-Demande-en-Têtes, de Contrôle d'Accès-Demande-Méthode)

Voici la configuration qui a résolu notre problème.

Compartiment S3 / Autorisations / CORS de configuration:

<?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 / Modifier le Comportement:

enter image description here


Nous avons maintenant l'expérience d'un problème similaire à la vôtre, comme nous venons de migrer notre CSS pour Webpack. Nous vivons encore plus sporadique de la SCRO erreurs de fichiers CSS. Nous essayons de supprimer l' crossorigin="anonymous" attribut <link rel="stylesheet" /> tags puisque nous n'avons pas besoin de l'erreur de suivi pour les fichiers CSS.

4voto

Reinhard Points 31

Je peux jeter un peu de lumière à la façon dont il est arrivé avec nous. Azure CDN (que nous utilisons) ne prend pas en charge Varient: les en-têtes de la droite maintenant. C'est très mauvais. Mais maintenant, nous utilisons le script crossorigin attribut qui - et c'est la chose la plus intéressante, n'est pas pris en charge par certains navigateurs.

Si tel navigateur, vient à notre site, il n'envoie pas d'origine: parce qu'il ne comprend pas le "crossorigin" attribut. Si, plus tard, un autre vient qui le comprend, il va envoyer origine: -> la SCRO Erreur parce que la première réponse est mis en cache.

Laid.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X