Décharger les redirections non regex vers Fastly au lieu de Nginx (itinéraires)

Créez un dictionnaire Edge.

Tout d’abord, vous pouvez utiliser des VCL fragments de code dans Adobe Commerce pour définir un dictionnaire de périphérie. Il contiendra les redirections.

Quelques mises en garde à ce sujet :

• Fastly ne pouvez pas effectuer de regex sur les entrées du dictionnaire. C’est juste une correspondance exacte. Pour plus d’informations sur ces limitations, consultez la documentation de Fastly sur les limitations des dictionnaires Edge.

• Fastly est limité à 1 000 entrées dans un seul dictionnaire. Fastly pouvez augmenter cette limite, mais cela nous amène au troisième avertissement.

• Chaque fois que vous mettez à jour les entrées et déployez ce VCL mis à jour sur tous les nœuds, le temps de chargement géométrique augmente avec les dictionnaires en expansion, ce qui signifie qu’un dictionnaire de 2 000 entrées se charge en fait 3 à 4 fois plus lentement qu’un dictionnaire de 1 000 entrées. Mais ce problème ne se pose que lorsque vous déployez le VCL (mise à jour du dictionnaire ou modification du code de la fonction VCL).

  Cela n’a aucune incidence sur le temps nécessaire au Fastly de traitement d’une demande ; cela a simplement une incidence sur le temps qu’il Fastly faut pour pousser une nouvelle configuration.

  En règle générale, les modifications de configuration prennent quelques secondes en moyenne, généralement pas plus de 5 à 10 secondes. Ainsi, une multiplication par 2 des éléments du dictionnaire prend plus de 30 secondes pour déployer votre configuration. Une augmentation de 4 fois prendrait près de 2 minutes. Cela nous amène à la quatrième mise en garde.

• Il y a une limite assez stricte de 10 000 entrées dans un dictionnaire Edge.

Il est vivement recommandé de consolider votre liste de redirections vers le bas. Vous pouvez utiliser plusieurs dictionnaires, mais sachez simplement que toute mise à jour de votre VCL prendra plusieurs minutes pour être réellement renseignée sur Fastly.

Comparez les URL au(x) dictionnaire(s).

Lorsque la recherche URL se produit, la comparaison est effectuée pour appliquer le code d’erreur personnalisé si une correspondance est trouvée.

Utilisez un autre fragment de code VCL pour ajouter un élément semblable au suivant à vcl_recv :

     declare local var.redir-path STRING;
     set var.redir-path = table.lookup(redirects, std.tolower(req.url), "");

     if (var.redir-path != "") {
       error 912 var.redir-path;
     }

Ici, nous vérifions si le URL existe dans l’entrée du tableau. Si c’est le cas, nous appelons une erreur de Fastly interne et transmettons à cette erreur le URL de redirection de la table .

Gérez la redirection.

Lorsqu’une correspondance est trouvée, l’action définie pour cette obj.status est exécutée, dans ce cas une redirection de déplacement permanent 301.

Utilisez un dernier fragment de code dans vcl_error pour renvoyer les codes d’erreur 301 au client :

  if (obj.status == 912) {
     set obj.http.location = obj.response;
     set obj.status = 301;
     set obj.response = "Moved Permanently";
     return(deliver);
       }

Avec ce bloc, nous vérifions si le code d’erreur transmis par vcl_recv correspond, et si c’est le cas, nous définissons l’emplacement sur le message d’erreur transmis, puis modifions le code d’état en 301 et le message en « Déplacé de manière permanente ». À ce stade, la réponse doit être prête à être renvoyée au client.