Bonjour, tout le monde, et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler des pages d'erreur personnalisées dans Cloud Front.
En général, disposer d'une page d'erreur client est l'une des choses les plus importantes, pas seulement pour
l'environnement basé sur le cloud, mais pour tout site Web.
Il est important que vous définissiez les pages clients, alors allons-y et examinons-les.
Tout d'abord, examinons le défi global.
Maintenant, dans une architecture basée sur le cloud, vous avez une origine et vous avez un client.
Ainsi, le code d'état et la page d'erreur que l'ami du nuage reçoit de l'origine sont également renvoyés à l'observateur.
Et encore une fois, cela pourrait ne pas créer une meilleure des expériences.
Par exemple, dans cette capture d'écran spécifique, vous verrez que l'utilisateur a demandé un fichier appelé
test txt et dans la réponse, il s'agit d'une réponse basée sur x HTML avec l'accès refusé, et il montre diverses choses comme
l'ID de la demande, l'ID de l'hôte, etc.
En général, dans les sites Web, vous ne voulez pas vraiment que ce type de réponse soit renvoyé à l'utilisateur.
Vous avez besoin d'une réponse plus générique qui devrait être servie.
C'est là que les pages d'erreur personnalisées entrent en jeu.
Désormais, dans le cadre de l'impression en nuage, vous pouvez la configurer pour envoyer une réponse d'erreur personnalisée
au visualiseur, différente de la réponse d'origine.
Ce diagramme permet de mieux comprendre la situation : il y a l'utilisateur, l'impression
en nuage et un triple seau où est hébergé un site web.
Ainsi, l'utilisateur envoie une demande au nuage, le nuage d'impression et envoie la demande à l'origine ; l'origine
renvoie une réponse à l'entreprise du nuage indiquant http 403 accès refusé.
Maintenant, à ce stade, le cloud front, quand il reçoit, vous pouvez configurer un ensemble différent de réponses
à envoyer à l'utilisateur.
Donc si vous voyez que la réponse est différente, y compris le code d'état.
Donc ici le code d'état HTTP est pour zéro trois accès refusé.
Cependant, le code d'état qui est envoyé par la firme du nuage est pour zéro quatre, qui n'est pas trouvé.
Très bien.
Alors faisons une chose.
Allons-y et examinons cela de façon pratique.
Si vous examinez les sites Web les plus importants, vous trouverez une sorte de page d'erreur personnalisée,
par exemple, dans la documentation.
Si nous demandons simplement un objet qui n'existe pas au lieu de la police plane 404 naught, vous voyez que vous avez une très
belle réponse qui est également utile et donne de bien meilleures informations.
Maintenant, dans une distribution en nuage qui n'a pas la page d'erreur personnalisée qui est configurée,
si vous demandez un objet inexistant ou essayons-le.
Vous voyez que vous avez obtenu la réponse XML typique indiquant que l'accès est refusé et ainsi de suite.
Comme nous le disions, il s'agit donc d'un élément que vous ne voulez pas renvoyer à vos utilisateurs.
Au lieu de cela, vous configurez une page d'erreur personnalisée au niveau de l'impression en nuage et la réponse peut être
améliorée.
Maintenant, j'ai une autre distribution de cloud firm avec une page d'erreur personnalisée qui est configurée,
alors remplaçons l'URL par la distribution la plus récente et j'ajouterai juste un texte aléatoire ici.
Appuyons sur Entrée et cette fois, vous verrez que la réponse est un peu différente.
Qui déclare : "Désolé, la page n'est pas disponible".
Vous pouvez avoir une page beaucoup plus propre ici.
Cependant, pour plus de simplicité, j'ai simplement ajouté un document texte ici avec les détails et dans les sites Web vous
aurez quelque chose comme ceci ou vous aurez une sorte d'image qui rend les choses beaucoup plus
belles.
Maintenant, laissez-moi aussi vous montrer rapidement comment vous pouvez configurer ceci.
Donc, pour simplifier, j'ai une distribution de nuage et celle-ci est à son tour associée à l'origine
de S3 Bucket.
Le site web est donc hébergé dans S3.
Maintenant, si vous regardez la distribution et la page d'erreur, j'ai une page d'erreur qui est configurée
ici.
Ainsi, si l'ami du nuage reçoit un accès refusé 403, qui est cette page spécifique que nous avons
vue précédemment, au lieu d'envoyer cela, il suffit d'envoyer la réponse qui fait partie du fichier
HTML de la page d'erreur personnalisée.
Et là où ce fichier est stocké, il est stocké dans le même que trois seaux.
Vous avez donc une page d'erreur personnalisée en HTML.
Ce fichier sera donc renvoyé au lieu de 403.
Si tout fonctionne, le fichier HTML de l'index sera renvoyé.
Maintenant, une autre chose intéressante que vous verrez est que le code d'état HTTP est également modifié.
Donc ici le code d'erreur est 403.
Cependant, le code de réponse HTTP ici est pour zéro quatre.
Ainsi, au lieu d'envoyer un message de refus d'accès à l'utilisateur, Cloud Front enverra une page non trouvée.
Et cela peut aussi être configuré.
Maintenant, examinons aussi rapidement cette question.
Alors faisons une chose.
Revenons à la distribution.
La page d'erreur personnalisée est configurée dans l'une des distributions.
Le deuxième n'a pas la page d'erreur personnalisée configurée.
Tout d'abord, examinons la distribution en nuage, qui n'a pas la page d'erreur configurée maintenant à partir
du Scylla.
Si je fais rapidement une boucle vers le.
Distribution et nous savons que l'objet n'existe pas.
Regardons dans l'en-tête.
L'en-tête ici est pour zéro trois interdit.
Regardons maintenant la distribution en nuage, qui a la page d'erreur configurée.
Je vais refaire une demande de curl.
Vous l'envoyez à un objet qui n'existe pas vraiment.
L'idéal serait que le troisième envoie ce message de retour 4034 à l'ami du nuage.
Cependant, cette fois, vous voyez que le code d'état HTTP est également changé en 404.
Il s'agit donc d'un élément que vous pouvez facilement configurer au niveau du cloud également.
Maintenant, généralement lorsque vous configurez les pages d'erreur.
Vous devez définir le code d'erreur HTTP.
Par exemple, si l'origine renvoie ce message 404 not found au cloud front, vous pouvez personnaliser
le message d'erreur ici.
Et ici, vous pouvez spécifier quel est le fichier qui doit être renvoyé.
Dans ce cas, le fichier est le HTML de la page d'erreur personnalisée, vous pouvez donc le spécifier ici.
Il est également possible d'envoyer un code d'état HTTP différent.
Ainsi, au lieu de 404 not found par l'origine, vous pouvez dire quelque chose comme 400 bad requests ou tout autre
code de statut en fonction de la grille d'exigences.
Il s'agit donc d'un aperçu de très haut niveau de l'envoi de la réponse d'erreur personnalisée à l'utilisateur.
Et c'est ainsi que se termine la vidéo d'aujourd'hui.