Gestion des redirections HTTP
Présentation
La gestion des redirections est une exigence courante sur les sites Web, souvent utilisée pour rediriger des URL inexistantes (par exemple, des campagnes expirées ou suite à un changement de structure de site Web), ou pour localiser le contenu en fonction du pays. Les redirections peuvent être gérées à l'origine ou au niveau du CDN. La gestion des redirections au niveau du CDN pourrait réduire la charge sur l'origine et réduire les temps de réponse. Dans certains cas, comme avec un hébergement statique (par exemple S3), les redirections ne peuvent pas être gérées sur l'origine. Les redirections sur CloudFront sont gérées à l'aide de ses fonctions de périphérie.
Décisions architecturales
Les redirections peuvent être implémentées de différentes manières à l'aide des fonctions de périphérie, en fonction de vos besoins. Pour concevoir la meilleure implémentation pour votre entreprise, posez-vous les questions suivantes
- À quelle fréquence mettez-vous à jour votre logique de redirection ? L'utilisation intensive des redirections en parallèle par différentes équipes nécessite une implémentation plus sophistiquée par rapport à des tests A/B plus simples et occasionnels.
- Combien de règles de redirection avez-vous dans votre logique ? La taille de la base de données de redirections est un facteur à prendre en compte lors de l'évaluation des différentes options de stockage.
- Les redirections sont-elles statiques ou dynamiques (par exemple, varient en fonction du pays de l'utilisateur ou des capacités de l'appareil) ? Lorsqu'elle est dynamique, la logique de redirection doit être exécutée dans un contexte où tous les paramètres nécessaires sont disponibles pour faire varier la réponse.
- Réécrivez-vous l'URL de manière transparente pour l'utilisateur ou envoyez-vous une redirection 3xx ?
Pour en savoir plus sur certaines implémentations de redirections utilisant les fonctions de périphérie de CloudFront, pensez à suivre cet atelier pratique. Dans la section suivante, nous allons partager deux implémentations courantes de la gestion des redirections à l'aide de CloudFront.
Cas d'utilisation courants
Redirections HTTP statiques
Si vous souhaitez implémenter des redirections HTTP avec quelques règles qui changent rarement, configurez une fonction CloudFront lors de l'événement de demande de la visionneuse avec une logique de redirections intégrée dans le code de la fonction. Lorsque la logique de redirection évolue, vous pouvez mettre à jour le code de la fonction et la nouvelle logique sera appliquée aux utilisateurs en quelques secondes.
Par exemple, la fonction CloudFront suivante, configurée lors d'un événement de demande d'utilisateur, envoie une réponse HTTP 3xx aux utilisateurs de certains pays (Espagne et Émirats arabes unis) pour les rediriger vers la version locale d'une application à page unique (par exemple https://example.com/ -> https://example.com/es/). Pour que cela fonctionne, vous devez inclure l'en-tête cloudfront-viewer-country dans la politique de demande d'origine. Elle demande à CloudFront de rendre cet en-tête disponible dans l'objet d'événement CloudFront Function, utilisé par votre logique de fonction. Notez que dans cet exemple de code, l'utilisateur est redirigé en fonction de son pays, sauf s'il demande spécifiquement une version du SPA pour un pays différent.
function handler(event) {
var request = event.request;
var headers = request.headers;
var host = request.headers.host.value;
var supported_countries = ['ie','ae', 'es']; // countries in which you'd like to serve a localized version of your Single Page Application
var defaultCountryIndex = 0; // default country index in the support_countries array. here it is 'ie'
if ((supported_countries.includes(request.uri.substring(1,3))) && ((request.uri.substring(3,4) === '/') || (request.uri.length === 3))) {
// If one of the supported country codes is included in the path (e.g. /es/about) then add index.html when needed to the reauest
return requestWithIndexHTML(request);
} else if ((headers['cloudfront-viewer-country']) && (headers['cloudfront-viewer-country'].value.toLowerCase() !== supported_countries[defaultCountryIndex])){
// Otherwise if the user reauest is coming from one of the supported countries except the default one, then redirect to country specific version (e.g. /about -> /es/about)
var response = {
statusCode: 302,
statusDescription: 'Found',
headers: { location: { value: `https://${host}/${headers['cloudfront-viewer-country'].value.toLowerCase()}${request.uri}` } },
};
return response;
} else {
// Otherwise send rewrite the request to the default country path, add index.html if needed and return
request.uri = '/'+supported_countries[defaultCountryIndex] + request.uri;
return requestWithIndexHTML(request);
}
}
// Add index.html to SPA path when needed
function requestWithIndexHTML(request) {
if (request.uri.endsWith('/')) {
request.uri += 'index.html';
} else if (!request.uri.includes('.')) {
request.uri += '/index.html';
}
return request;
}Redirections HTTP en masse
La fonction CloudFront est également capable de prendre en charge des mappages de redirection plus importants à l'aide de CloudFront KeyValueStore, au-delà de ce que vous pouvez intégrer dans les limites de la taille de fonction maximale de 10 Ko. Par exemple, vous pouvez stocker les URI que vous souhaitez comparer dans les clés et les URL de redirection dans la valeur. L'URI disponible dans l'objet d'événement de la demande de la visionneuse peut être évalué pour un URI correspondant et, s'il en existe un dans les clés, votre fonction peut renvoyer une redirection 3xx avec la valeur associée.
L'utilisation de KeyValueStore présente également l'avantage de découpler de votre code les données qui changent régulièrement. Le KeyValueStore est idéal en tant qu'entrepôt de données de valeurs clés globale (chaque PoP), à faible latence et à grande échelle (des millions de requêtes par seconde).
Exigences avancées pour les redirections HTTP
Une solution basée sur Lambda@Edge est plus adaptée aux exigences de redirection avancées, qui ne peuvent pas être satisfaites par la taille maximale de KeyValueStore (5 Mo) ou par une limite de vitesse modifiée de quelques appels d'API par seconde. Un exemple de scénario est celui où de nombreuses équipes marketing mettent à jour des centaines de milliers de redirections de campagnes quotidiennement.
Dans cette architecture, une fonction Lambda@Edge, configurée sur un événement de demande d'origine, est exécutée à chaque absence de cache afin de vérifier auprès d'un stockage de règles externe tel que S3 ou DynamoDB, quelle règle de redirection appliquer. Les règles sont gérées directement dans le stockage sélectionné, avec la possibilité de créer une interface utilisateur simple par-dessus pour faciliter la gestion. Un exemple de cette architecture, avec un stockage basé sur S3 et une interface utilisateur de gestion authentifiée, est décrit dans ce blog.
