Comment résoudre «x-cache: erreur de cloudfront» sur SPA
Nous rencontrons des problèmes pour essayer de faire fonctionner un SPA avec un routeur client (routeur React). Nous utilisons le concept d'avoir une DOMAIN -> CDN (CloudFront) -> S3 pour servir nos fichiers statiques.
Nous avons configuré le S3 pour servir des fichiers statiques. Le CDN est configuré pour avoir l'origine du S3 et nous avons configuré des pages d'erreur personnalisées pour détecter les erreurs:
avec cette configuration, nous pouvons détecter des erreurs comme celle-ci:
https://www.example.com/custom-url
Le CDN redirigera toutes les erreurs 404/403 vers le principal index.html et react router obtiendra le routage correct.
Nous travaillons sur notre site et le routeur client fonctionne correctement, mais nous avons un problème avec la réponse de notre CDN avec x-cache: Error from cloudfront:
Si nous accédons à l'url principale https://www.example.com sans paramètre de requête (pas de chaîne de requête), tout fonctionne bien.
Comment puis-je résoudre ce problème et faire en sorte que toutes mes URL dynamiques fonctionnent?
Merci.
Amazon CloudFront peut devenir délicat avec sa configuration et le débogage d'un code d'erreur - pour remonter à sa cause racine peut prendre plusieurs heures. Cependant, vous souhaiterez peut-être effectuer les vérifications suivantes avant d'accéder aux journaux.
Nom du seau!
Les noms de compartiment doivent correspondre aux noms du site Web que vous hébergez.
Par exemple, pour héberger votre-domaine.com site Web sur Amazon S3, vous créeriez un compartiment nommé votre- domain.com .
Pour héberger un site Web sous www.your-domain.com , vous devez nommer le compartiment www.your-domain .com .
C'est une meilleure pratique, pour créer des compartiments pour your-domain.com et www.your-domain.com.
Utilisez la logique existante dans vos paramètres/configuration pour l'un de ces compartiments et utilisez-la pour servir le site Web statique. Utilisez l'autre compartiment pour rediriger la demande vers le compartiment d'origine.
Honnêtement, cela ne vous poserait pas de problème puisque vous avez intégré votre système à Amazon CloudFront, qui peut être configuré pour utiliser un compartiment Amazon S3 de n'importe quel nom.
Avec Amazon CloudFront, les utilisateurs qui visitent votre domaine récupèrent directement les données de la distribution CloudFront qui, à son tour, met en cache le contenu de notre compartiment S3.
Configuration des paramètres d'origine de la distribution.
Lors de la création d'une distribution avec Amazon CloudFront, notez le point de terminaison Amazon S3 associé avec le nom de domaine d'origine. Assurez-vous d'utiliser le point de terminaison du site Web et [~ # ~] pas [~ # ~] le point de terminaison REST N'utilisez pas le point de terminaison suggéré automatiquement par CloudFront.
Il y a une différence de comportement comme expliqué dans Amazon Web Services documentation officielle
4XX Code d'erreur!
À partir des journaux de votre console, il suggère que l'instance de distribution tente d'accéder à un élément, une page ou une ressource interdite et donc au code d'état 403.
Alors que le 404 est simplement le résultat d'une page introuvable. Cependant, après la redirection d'erreur - telle que gérée dans votre configuration, l'utilisateur est redirigé vers index.html où il rencontre le 403.
Plus d'informations sur - Comment CloudFront traite et met en cache les codes d'état HTTP 4xx et 5xx de votre origine
Les autres suspects habituels incluent les configurations de mise en cache pour la distribution Amazon CloudFront, les paramètres AWS Route53 et Amazon Certificate Manager.
Comme mentionné au début, cela peut devenir assez déroutant lors du suivi de ces erreurs. Faites-nous savoir si ce qui précède aide. De plus, j'apprécierais vraiment que vous puissiez publier des mises à jour sur vos enquêtes et conclusions.
Merci pour la lecture.