Cloudflare Waiting Room protège les sites contre les surcharges liées aux pics de trafic en transférant l'excédent de visiteurs vers une salle d'attente virtuelle, entièrement personnalisable, dans laquelle les visiteurs sont admis dynamiquement, au fur et à mesure que des places se libèrent. Au lieu d'afficher des pages d'erreur ou de proposer une expérience insatisfaisante de l'affichage des pages du site, Waiting Room permet aux clients de prendre le contrôle de l'expérience de leurs utilisateurs finaux pendant les pics de trafic ingérables.
L'une des principales décisions que prennent les clients lors de la configuration d'une salle d'attente consiste à sélectionner les pages que protégera celle-ci. Jusqu'à présent, les clients pouvaient sélectionner un nom d'hôte et un chemin d'accès lors de la désignation des pages protégées par une instance de Waiting Room. Aujourd'hui, nous sommes ravis d'annoncer que Waiting Room propose désormais la prise en charge de combinaisons de noms d'hôtes et de chemins d'accès multiples pour une salle d'attente unique, offrant ainsi aux clients davantage de flexibilité et une prise en charge plus étendue des sites, sans interruption des flux des utilisateurs finaux.Cette nouvelle fonctionnalité est accessible à tous les clients Enterprise ayant préacheté Waiting Room.
Ajout d'un site dans Waiting Room
Le déploiement d'une salle d'attente est une procédure simple et sans codage, durant laquelle les clients spécifient une combinaison de nom d'hôte et de chemin d'accès afin de désigner les pages prises en charge par une salle d'attente particulière. Lorsqu'un visiteur du site transmet une requête préliminaire à ce nom d'hôte et ce chemin d'accès ou l'un de ses sous-chemins, il reçoit un cookie correspondant à la salle d'attente et est ensuite admis sur le site ou transféré vers une salle d'attente, si le site est saturé.
L'année dernière, nous avons ajouté la fonctionnalité Waiting Room Bypass Rules, qui offre aux clients de nombreuses options permettant de créer des exceptions à cette prise en charge des noms d'hôtes et des chemins d'accès. Cette fonctionnalité a débloqué des capacités telles que le contournement d'agent utilisateur, le ciblage par géolocalisation, les exclusions d'URL et le contournement d'adresses IP d'administration. Elle a également offert davantage de flexibilité au regard de la prise en charge par Waiting Room des pages du site d'un client en ajoutant la possibilité d'exclure des URL, des chemins d'accès et des chaînes de requête. Si cette mise à jour a permis de mieux définir le trafic devant être filtré par Waiting Room, elle n'offrait néanmoins pas la prise en charge étendue que recherchaient encore de nombreux clients pour protéger de plus vastes pans de leurs sites avec une salle d'attente unique.
Pourquoi les clients avaient besoin d'une prise en charge plus étendue par Waiting Room
Examinons quelques exemples simples, mais pertinents, des raisons pour lesquelles cette option de prise en charge étendue était importante pour nos clients. Imaginons que vous ayez une boutique en ligne, example.com, et que vous souhaitiez vous assurer qu'une salle d'attente unique couvre l'ensemble du parcours du client – de la page d'accueil jusqu'à la navigation sur les produits, puis au paiement. De nombreux sites emploient les chemins pour délimiter ces étapes au sein du flux : example.com/, example.com/shop/product1, example.com/payment. Puisque Waiting Room suppose qu'un caractère générique implicite est présent à la fin du chemin d'accès configuré pour une salle d'attente, ce scénario d'utilisation était déjà pris en charge pour ces sites. Ainsi, la configuration d'une salle d'attente à l'adresse example.com/ permettrait de couvrir toutes les URL associées à chaque étape du parcours du client. Dans cette configuration, lorsqu'un visiteur consultant le site avait traversé la salle d'attente, il ne réintégrait pas la file d'attente à une étape ultérieure de son parcours d'utilisateur, car il disposait toujours du même cookie correspondant à la salle d'attente, qui indique à Waiting Room qu'il s'agit d'un même utilisateur parcourant les différentes URL.
Cependant, de nombreux sites utilisent des sous-domaines à la place des chemins d'accès, ou conjointement à ceux-ci, pour délimiter les différentes étapes de ce type de parcours d'achat. Par exemple, la page de paiement de nombreux sites se trouve sur un sous-domaine différent, comme payment.example.com. Jusqu'à présent, si un client disposait de cette structure de site et souhaitait protéger l'ensemble de son site avec une salle d'attente unique, il devait configurer une première salle d'attente à l'adresse example.com/, et une deuxième salle d'attente à l'adresse payment.example.com/. Cette option était peu pratique pour de nombreux clients, car un visiteur pouvait se retrouver ajouté à une file d'attente à deux endroits différents du même parcours client. En effet, la salle d'attente de payment.example.com/ compterait le même visiteur comme un autre utilisateur de celui de la salle d'attente couvrant example.com/.
Cela étant dit, dans certains cas, il est judicieux de séparer les salles d'attente couvrant un même site. Par exemple, un site web de billetterie pourrait déployer une salle d'attente sur son domaine racine (example.com), puis déployer des salles d'attente distinctes avec des pré-files d'attente sur les pages consacrées à des événements spécifiques (example.com/popular_artist_tour). La salle d'attente de la page example.com/ permet d'éviter que le principal point d'accès au site ne soit submergé par les requêtes et que le site devienne inaccessible lors de l'ouverture de la vente de billets pour un événement donné. La salle d'attente placée sur la page de l'événement spécifique assure que le trafic correspondant à un événement particulier puisse être mis en file d'attente avant l'événement, sans toutefois affecter le trafic affluant vers d'autres parties du site.
En fin de compte, peu importe qu'un client souhaite déployer une ou plusieurs salles d'attente pour protéger son site : nous souhaitions offrir à chaque client la possibilité de déployer Waiting Room de la manière la plus adaptée à ses scénarios d'utilisation et sa structure de site. Nous sommes ravis d'annoncer que Waiting Room offre désormais la prise en charge de noms d'hôtes et de chemins d'accès multiples dans une salle d'attente unique !
Découvrir la prise en charge d'hôtes et de chemins d'accès multiples
Les clients peuvent désormais configurer une salle d'attente avec plusieurs combinaisons de noms d'hôtes et de chemins (ou d'itinéraires) appartenant à une même zone. Pour cela, accédez à Trafic > Waiting Room, puis sélectionnez Create (Créer). Le nom de votre domaine sera déjà renseigné. Pour ajouter des itinéraires supplémentaires à la configuration de votre salle d'attente, sélectionnez Add Hostname (Ajouter un nom d'hôte), puis Path (Chemin d'accès). Vous pouvez ensuite saisir un autre nom d'hôte et un autre chemin d'accès qui seront couverts par la même salle d'attente. N'oubliez pas qu'un caractère générique implicite est inclus après chaque chemin d'accès ; il n'est donc pas nécessaire de créer une salle d'attente pour chaque URL que vous souhaitez couvrir. Créez uniquement des itinéraires supplémentaires pour les URL qui ne seraient pas couvertes par les autres combinaisons de noms d'hôtes et de chemins d'accès que vous avez déjà spécifiées.
Lorsque vous déployez une salle d'attente couvrant plusieurs combinaisons de noms d'hôtes et de chemins d'accès, vous devez créer un nom de cookie unique pour cette salle d'attente (nous y reviendrons plus tard). Ensuite, appliquez le même flux de travail que d'habitude pour déployer votre salle d'attente.
Déployer une salle d'attente multilingue
Une demande fréquemment formulée par nos clients était la possibilité de couvrir un site multilingue avec une salle d'attente unique, en proposant des textes différents dans chaque langue, tout en comptabilisant l'ensemble du trafic du site dans les limites de la même salle d'attente. Il existe plusieurs façons de structurer un site pour à délimiter les différentes options linguistiques ; toutefois, les deux approches les plus courantes sont la délimitation par sous-domaine ou par chemin d'accès. Pour un site qui utilise la délimitation par chemin d'accès, cela pourrait se présenter ainsi : example.com/en et example.com/es pour l'anglais et l'espagnol, respectivement. Pour un site utilisant la délimitation par sous-domaine, la configuration pourrait être la suivante : en.example.com/ et es.example.com/. Avant la prise en charge d'hôtes multiples par Waiting Room, la variation des sous-domaines n'aurait pas pu être couverte par une salle d'attente unique.
Les options de configuration existantes de Waiting Room prenaient déjà en charge les variations de chemin d'accès. Cependant, cela n'était vrai que si le client souhaitait couvrir l'ensemble du site, ce qui était réalisable en en plaçant la salle d'attente à l'adresse example.com/. De nombreux clients dans le secteur de l'e-commerce ont demandé la possibilité de couvrir différentes pages de produits très demandées, proposant le même produit, avec des options linguistiques différentes. Par exemple, prenons le cas de example.com/en/product_123 et de example.com/es/product_123. Pour ces pages, le client souhaite couvrir les deux URL avec la même salle d'attente et des limites de trafic identiques. Jusqu'à présent, cela n'aurait pas été possible sans configurer une logique complexe basée sur des règles de contournement.
Désormais, toutefois, les clients peuvent déployer une salle d'attente couvrant, au choix, l'approche basée sur les sous-domaines ou les chemins d'accès pour structurer un site multilingue. L'unique étape restante consiste à configurer votre salle d'attente afin qu'elle puisse servir différentes langues lorsqu'un utilisateur est transféré vers une salle d'attente. Pour cela, vous pouvez développer un modèle lisant l'URL afin de déterminer les paramètres régionaux, puis définir les traductions appropriées pour chaque langue dans le modèle.
Voici un exemple de modèle qui détermine les paramètres régionaux à partir du chemin d'accès de l'URL, puis affiche le texte traduit :
<!DOCTYPE html>
<html>
<head>
<title>Waiting Room powered by Cloudflare</title>
</head>
<body>
<section>
<h1 id="inline-msg">
You are now in line.
</h1>
<h1 id="patience-msg">
Thank you for your patience.
</h1>
</section>
<h2 id="waitTime"></h2>
<script>
var locale = location.pathname.split("/")[1] || "en";
var translations = {
"en": {
"waittime_60_less": "Your estimated wait time is {{waitTime}} minute.",
"waittime_60_greater": "Your estimated wait time is {{waitTimeHours}} hours and {{waitTimeHourMinutes}} minutes.",
"inline-msg": "You are now in line.",
"patience-msg": "Thank you for your patience.",
},
"es": {
"waittime_60_less": "El tiempo de espera estimado es {{waitTime}} minuto.",
"waittime_60_greater": "El tiempo de espera estimado es {{waitTimeHours}} de horas y {{waitTimeHourMinutes}} minutos.",
"inline-msg": "Ahora se encuentra en la fila de espera previa.",
"patience-msg": "Gracias por su paciencia.",
}
};
{{#waitTimeKnown}}
var minutes = parseInt( {{waitTime}} , 10);
var time = document.getElementById('waitTime');
if ( minutes < 61) {
time.innerText = translations[locale]["waittime_60_less"]
} else {
time.innerText = translations[locale]["waittime_60_greater"]
}
{{/waitTimeKnown}}
// translate template text for each of the elements with “id” suffixed with “msg”
for (const msg of ["inline-msg", "patience-msg"]) {
const el = document.getElementById(msg);
if (el == null) continue;
el.innerText = translations[locale][msg];
}
</script>
</body>
</html>
Voici comment fonctionne le modèle : puisqu'un site distingue différents paramètres régionaux avec différents chemins tels que `/en/product_123` ou `/es/product_123` dans le corps `<script />` après avoir effectué le rendu de la page, le paramètre régional est extrait de `location.pathname` via `locale = location.pathname.split(“/”)[1]`. Si aucune langue n'est spécifiée dans l'objet `translations`, la valeur par défaut est « en ». Par exemple, si un utilisateur consulte le site example.com/product_123, par défaut, le site affiche le rendu du modèle de texte anglais.
De même, pour prendre en charge une salle d'attente multilingue pour les sites délimitant la structure du site par sous-domaine, il suffirait de modifier la manière dont le paramètre régional est extrait de l'URL. Au lieu d'examiner `pathname`, nous examinons la propriété `hostname` de l'objet `window.location` (par exemple, `locale = location.hostname.split(“.”)[0]`),étant donné que la structure de notre site est la suivante : en.example.com, es.example.com.
Le code présenté ci-dessus est un exemple réduit des modèles de démarrage que nous avons ajoutés à notre documentation pour développeurs afin de faciliter la configuration d'une salle d'attente multilingue. Vous pouvez télécharger ces modèles et les modifier afin d'adapter leur apparence et leur fonctionnalité à votre site et aux options linguistiques proposées par celui-ci.
Ces modèles peuvent être étendus pour inclure d'autres langues en ajoutant des traductions à l'objet `translations` pour chacun des paramètres régionaux. Un modèle unique peut ainsi servir plusieurs langues en fonction des paramètres régionaux définis pour le site, qu'il s'agisse d'un sous-domaine ou d'un chemin d'accès.
Comment nous gérons les cookies avec une salle d'attente couvrant plusieurs noms d'hôtes et chemins d'accès
La salle d'attente alloue à chaque utilisateur un cookie `__cfwaitingroom` permettant de gérer son état ; ce cookie détermine la position de l'utilisateur dans la file d'attente, ainsi que d'autres propriétés nécessaires pour prendre les décisions de mise en file d'attente. Traditionnellement, pour une configuration comportant un nom d'hôte et un chemin d'accès uniques, il était extrêmement simple de définir le cookie comme ceci : `__cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123`. Ainsi, lorsque la page était actualisée, elle transmettait le même cookie Waiting Room, nous permettant de l'examiner et de le mettre à jour. Toutefois, cette procédure devenait beaucoup moins simple lorsque nous voulions partager le même cookie pour différentes combinaisons de sous-domaines ou de chemins d'accès, par exemple, `example.com/en/product_123`.
Approches de la configuration de plusieurs cookies
Nous avons envisagé et évalué deux approches permettant le partage du cookie pour une même salle d'attente.
La première approche que nous avons envisagée consistait à insérer plusieurs en-têtes `Set-Cookie` dans la réponse HTTP. Par exemple, dans l'exemple multilingue ci-dessus, nous pourrions ajouter les indications suivantes dans l'en-tête de la réponse :
Set-Cookie: __cfwaitingroom=[cookie-value]…Domain=example.com; Path=/en/product_123 …
Set-Cookie: __cfwaitingroom=[cookie-value]...Domain=example.com; Path=/es/product_123 …
Cette approche nous permettrait de gérer plusieurs noms d'hôtes et chemins d'accès pour une même salle d'attente. Cependant, elle ne constitue pas une solution très évolutive. Conformément à RFC6265, aucune limite stricte n'est définie dans la spécification ; les navigateurs comportent des limites particulières, spécifiques à l'implémentation. Par exemple, Chrome accepte une taille d'en-tête de 256 K octets avant de renvoyer l'erreur ERR_RESPONSE_HEADERS_TOO_BIG pour la transaction. Par ailleurs, dans ce cas, la taille de l'en-tête de réponse augmenterait proportionnellement au nombre de combinaisons uniques de noms d'hôtes et de chemins d'accès et, de manière redondante, nous répéterions N fois (où N représente le nombre d'itinéraires supplémentaires) la même valeur de cookie. Cette approche nous aurait permis de gérer efficacement une liste restreinte de combinaisons de noms d'hôtes et de chemins d'accès à définir ; toutefois, elle n'était pas idéale dans les situations où un site particulier comportait plus qu'un nombre limité d'itinéraires.
La deuxième approche à laquelle nous avons réfléchi, et que nous avons choisie, consistait à placer le cookie sur le domaine racine (ou le sous-domaine le plus courant). En d'autres termes, nous déterminons le sous-domaine le plus courant à partir de la liste des itinéraires, et nous l'utilisons comme domaine. De manière similaire, pour les chemins d'accès, il s'agirait de déterminer le préfixe le moins commun à partir de la liste des chemins d'accès et de l'utiliser comme valeur à définir par l'attribut de chemin d'accès. Prenons l'exemple d'une salle d'attente pour laquelle les deux itinéraires suivants ont été configurés : a.example.com/shoes/product_123 et b.example.com/shoes/product_456.
Pour déterminer le domaine défini pour le cookie, nous voyons que `example.com` est le sous-domaine le plus courant parmi la liste des domaines. L'application de l'algorithme du sous-domaine le plus courant renverrait le domaine `example.com` ; en revanche, l'application de l'algorithme du préfixe le moins courant à l'ensemble de chemins d'accès `/shoes/product_123` et `/shoes/product_456` renverrait le chemin d'accès `/shoes`. Par conséquent, l'en-tête Set-Cookie serait le suivant :
Set-Cookie: … __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/shoes …
Désormais, lorsqu'un visiteur accède à l'une des pages couvertes par cette salle d'attente, nous pouvons garantir que Waiting Room reçoit le bon cookie et que l'en-tête de la réponse contiendra uniquement `Set-Cookie`.
Cependant, la configuration n'est pas encore terminée. Bien que nous soyons en mesure d'identifier le sous-domaine commun (ou domaine racine) et le préfixe de chemin d'accès commun, un problème demeurerait si les itinéraires correspondant à une salle d'attente étaient identiques à ceux définis pour une autre salle d'attente. Par exemple, supposons que nous configurions deux salles d'attente pour un même site, sur lequel nous vendons nos chaussures spéciales :
Salle d'attente A
a.example.com/shoes/product_123
b.example.com/shoes/product_456
Salle d'attente B
c.example.com/shoes/product_789
d.example.com/shoes/product_012
Si nous appliquons le même algorithme que celui décrit ci-dessus, nous obtiendrons les mêmes propriétés de domaine et de chemin d'accès pour les deux cookies. Pour la salle d'attente A, le domaine serait `example.com` et le chemin d'accès serait `/shoes`. De même, pour la salle d'attente B, le sous-domaine le plus courant serait également example.com, et le préfixe de chemin d'accès le moins courant serait `/shoes`. Concrètement, ceci nous empêcherait de distinguer les deux cookies et de rediriger le visiteur vers la salle d'attente correcte. Afin de résoudre le problème du chevauchement des noms de cookies, nous avons introduit la nécessité de définir un suffixe personnalisé unique pour la zone du client. C'est pourquoi il est nécessaire de spécifier un suffixe de cookie personnalisé lors de la configuration d'une salle d'attente couvrant plusieurs noms d'hôtes ou chemins d'accès. Par conséquent, si la salle d'attente A reçoit le suffixe de cookie « a » et la salle d'attente B le suffixe de cookie « b », les deux définitions de `Set-Cookie` se présenteront comme ceci :
Salle d'attente A
Set-Cookie: __cfwaitingroom_a=[cookie-value]; Domain=example.com; Path=/shoes
Salle d'attente B
Set-Cookie: __cfwaitingroom_b=[cookie-value]; Domain=example.com; Path=/shoes
Lorsqu'un visiteur transmet une requête à une page pour laquelle ces deux salles d'attente différentes sont configurées, Waiting Room peut distinguer et sélectionner le cookie correspondant à la requête transmise et l'utiliser pour déterminer les paramètres de la salle d'attente applicables à cet utilisateur en fonction de l'endroit où il se trouve sur le site.
Avec l'ajout de la prise en charge de plusieurs hôtes et chemins d'accès par Waiting Room, nous sommes ravis de proposer des options plus flexibles pour l'incorporation de Waiting Room sur votre site, et ainsi, d'offrir à vos visiteurs la meilleure expérience possible, tout en protégeant votre site pendant les périodes d'affluence. Assurez-vous que votre site est toujours protégé contre les pics de trafic. Essayez dès aujourd'hui Waiting Room ou contactez-nous pour en savoir plus sur la solution Advanced Waiting Room.