Cloudflare Waiting Room protege los sitios contra las sobrecargas vinculadas a los picos de tráfico, colocando el exceso de visitantes en una sala de espera virtual, completamente personalizable, donde son admitidos dinámicamente a medida que se liberan plazas. En lugar de mostrar páginas de error o entregar páginas del sitio con un bajo rendimiento, Waiting Room permite a los clientes tomar el control de su experiencia de usuario final durante los picos de tráfico inmanejables.
Una decisión clave que toman los clientes al configurar una sala de espera es acerca de qué páginas protegerán. Hasta ahora, los clientes podían seleccionar una sola combinación de nombre de host y ruta de acceso para determinar las páginas cubiertas por una sala de espera. Hoy nos complace anunciar que Waiting Room ahora ofrece compatibilidad con varias combinaciones de nombres de host y rutas de acceso con una sola sala de espera, y ofrece así a los clientes más flexibilidad y una cobertura más amplia del sitio sin interrupciones de los flujos de los usuarios finales. Esta nueva funcionalidad está disponible para todos los clientes Enterprise con una versión Advanced de Waiting Room.
Colocación de un sitio en Waiting Room
Durante la implementación de una sala de espera, un proceso sencillo y que no requiere codificación, los clientes especifican una combinación de nombre de host y ruta de acceso para indicar las páginas cubiertas por una sala de espera determinada. Cuando un visitante del sitio realiza una solicitud preliminar a ese nombre de host y esa ruta de acceso o a cualquiera de sus rutas de acceso secundarias, recibe una cookie correspondiente a la sala de espera y entonces se admite en el sitio o bien, si el sitio está saturado, se coloca en una sala de espera.
El año pasado añadimos la funcionalidad Waiting Room Bypass Rules, que ofrece a los clientes muchas opciones para crear excepciones a esta cobertura de nombre de host y ruta de acceso. Esta funcionalidad ha desbloqueado funciones como la omisión de agente de usuario, el filtrado por geolocalización, las exclusiones de URL y la omisión administrativa de direcciones IP. Asimismo, ha mejorado la flexibilidad en lo referente a las páginas a las que se debe aplicar una sala de espera en el sitio de un cliente, al añadir la posibilidad de excluir URL, rutas de acceso y cadenas de consulta. Aunque esta actualización permitió una mayor especificidad acerca del tráfico que debe filtrar Waiting Room, no ofrecía la cobertura más amplia que aún necesitaban muchos clientes para proteger áreas más extensas de sus sitios con una sola sala de espera.
Por qué los clientes necesitaban una cobertura más amplia de Waiting Room
Analicemos algunos ejemplos sencillos pero adecuados de por qué esta opción de una cobertura más amplia era importante para nuestros clientes. Imagina que tienes una tienda en línea, example.com, y quieres asegurarte de que una sola sala de espera cubre todo el recorrido del cliente, desde la página inicial a la navegación por los productos, y finalmente a la validación del pedido. Muchos sitios utilizan rutas de acceso para definir estos pasos en el flujo: example.com/, example.com/shop/product1, example.com/checkout. Puesto que Waiting Room supone que existe un comodín implícito al final de la ruta de acceso configurada para una sala de espera, este caso de uso ya estaba cubierto para estos sitios. Por lo tanto, la configuración de una sala de espera en la dirección example.com/ permitirá cubrir todas las URL asociadas con cada uno de los pasos de este recorrido del cliente. En esta configuración, una vez que un visitante del sitio entraba en la sala de espera, no se volvía a poner en cola en ningún otro paso del flujo del usuario, ya que seguía utilizando la misma cookie correspondiente a la sala de espera, lo que indica a Waiting Room que se trata del mismo usuario en distintas URL.
No obstante, muchos sitios utilizan subdominios en lugar de, o además de, rutas de acceso para definir distintos pasos de este tipo de flujo de compra. Por ejemplo, la página de validación del pedido de muchos sitios estará en un subdominio distinto, por ejemplo, checkout.example.com. Hasta ahora, si un cliente tenía esta estructura de sitio y quería proteger todo su sitio con una sola sala de espera, necesitaba implementar una sala de espera en la dirección example.com/ y otra en la dirección checkout.example.com/. Esta opción no era idónea para muchos clientes, puesto que un visitante del sitio podía encontrarse puesto en cola en dos lugares distintos del mismo recorrido de cliente. Esto se debe a que la sala de espera en la dirección checkout.example.com/ contabilizaría el mismo visitante como un usuario distinto que el de la sala de espera que cubre el sitio example.com/.
Dicho esto, en algunos casos es recomendable separar las salas de espera que cubren un solo sitio. Por ejemplo, un sitio web de venta de entradas podría implementar una sala de espera en su dominio raíz (example.com) y distintas salas de espera con pre-colas de espera en páginas dedicadas a eventos específicos (example.com/popular_artist_tour). La sala de espera definida en la página example.com/ garantiza que el punto de acceso principal al sitio no se sobrecargue y deje de estar accesible al abrir la venta de entradas para un evento específico. La sala de espera definida en la página dedicada al evento específico garantiza que el tráfico correspondiente a un evento determinado se pueda empezar a poner en cola de espera antes del evento sin afectar al tráfico que se dirige a otros lugares del sitio.
En definitiva, independientemente de si un cliente desea tener una o varias salas de espera para proteger su sitio, queríamos ofrecer a nuestros clientes la flexibilidad de implementar Waiting Room de la forma que se ajustara mejor a sus casos de uso y a su estructura del sitio. Nos complace anunciar que Waiting Room ahora admite la cobertura de varios nombres de host y rutas de acceso con una sola sala de espera.
Cómo empezar a utilizar la cobertura de varios hosts y rutas de acceso
Ahora los clientes pueden configurar una sala de espera en varias combinaciones de nombres de host y ruta (o rutas) de acceso correspondientes a la misma zona. Para ello, ve a Tráfico > Waiting Room y selecciona Create (Crear). El nombre de tu dominio ya estará rellenado. Para añadir reglas adicionales a la configuración de tu sala de espera, selecciona Add Hostname and Path (Añadir nombre de host y ruta de acceso). A continuación, puedes especificar otro nombre de host y ruta de acceso que desees que cubra la misma sala de espera. Recuerda que hay un comodín implícito al final de cada ruta de acceso. Por lo tanto, es innecesario crear una sala de espera para cada URL que desees que cubra tu sala de espera. Crea solo rutas de acceso adicionales para las URL que no estén cubiertas por las combinaciones de nombres de host y rutas de acceso que ya hayas especificado.
Al implementar una sala de espera que cubra varias combinaciones de nombres de host y rutas de acceso, debes crear un nombre de cookie exclusivo para esa sala de espera (más información más adelante). A continuación, continúa con el mismo flujo de trabajo de la forma habitual para implementar tu sala de espera.
Implementación de una sala de espera multilingüe
Los clientes nos han solicitado a menudo la posibilidad de cubrir un sitio multilingüe con una sola sala de espera, y ofrecer así texto específico para cada idioma al mismo tiempo que se contabiliza todo el tráfico del sitio en los mismos límites de la sala de espera. Hay varios métodos para estructurar un sitio a fin de definir las distintas opciones lingüísticas. Sin embargo, los dos más habituales son por subdominio o por ruta de acceso. Para un sitio que utilice la definición por ruta de acceso, podría presentarse así: example.com/en y example.com/es para inglés y español, respectivamente. Para un sitio que utilice la definición por subdominio, podría presentarse así: en.example.com/ y es.example.com/. Antes de que Waiting Room ofreciera la cobertura de varios hosts, la variación por subdominio no podría haber estado cubierta por una única sala de espera.
Las opciones de configuración existentes de Waiting Room ya admitían la variación por ruta de acceso. Sin embargo, esto solo era cierto si el cliente quería filtrar todo el sitio, lo que podía hacer definiendo la sala de espera en la página example.com/. Muchos clientes de comercio electrónico han solicitado la posibilidad de filtrar distintas páginas de productos con alta demanda que ofrecen el mismo producto pero con distintas opciones de idioma. Por ejemplo, considera example.com/en/product_123 y example.com/es/product_123, donde el cliente desea utilizar la misma sala de espera y aplicar los mismos límites de tráfico para cubrir ambas URL. Hasta ahora, esto no habría sido posible sin alguna compleja lógica de reglas de omisión.
Ahora, los clientes pueden implementar una sala de espera que se ajuste al método elegido de estructuración de un sitio multilingüe, ya sea por subdominio o por ruta de acceso. Para terminar, solo debes configurar tu sala de espera para que entregue distintos idiomas cuando un usuario se ponga en cola en una sala de espera. Para ello, puedes crear una plantilla que lea la URL a fin de determinar los parámetros de idioma y definir las traducciones adecuadas para cada idioma en la plantilla.
A continuación se muestra un ejemplo de una plantilla que determina los parámetros de idioma de la ruta de acceso de la URL, y que presenta el texto traducido:
<!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>
La plantilla funciona de la forma siguiente: si un sitio distingue entre distintos parámetros de idioma con distintas rutas de acceso, como /en/product_123 o /es/product_123 en el cuerpo <script /> después de representar la página, el parámetro de idioma se extrae de location.pathname mediante locale = location.pathname.split(“/”)[1]. Si no se ha especificado ningún parámetro de idioma en el objeto `translations`, por defecto utilizamos “en”. Por ejemplo, si un usuario visita example.com/product_123, por defecto se representa la plantilla con el texto en inglés.
De la misma forma, para admitir una sala de espera multilingüe correspondiente a sitios que definen la estructura del sitio por subdominio, únicamente deberías actualizar cómo extraer el parámetro de idioma de la URL. En lugar de comprobar `pathname`, comprobamos la propiedad `hostname` del objeto `window.location` como `locale = location.hostname.split(“.”)[0]`, nuestra estructura del sitio será la siguiente: en.example.com, es.example.com.
El código anterior es un ejemplo simplificado de las plantillas iniciales que hemos añadido a nuestra documentación para desarrolladores. Las hemos incluido para que te sea más fácil empezar a utilizar una sala de espera multilingüe. Puedes descargar estas plantillas y editarlas para que su aspecto se ajuste a tu sitio y a las opciones de idioma que este ofrece.
Estas plantillas se pueden ampliar para incluir otros idiomas añadiendo las traducciones al objeto `translations` para cada uno de los idiomas. De esta forma, una única plantilla puede entregar varios idiomas, en función del parámetro de idioma que se aplique al sitio, ya sea por subdominio o por ruta de acceso.
Cómo gestionamos las cookies con una sala de espera que cubre varios nombres de host y rutas de acceso
La sala de espera asigna una cookie __cfwaitingroom a cada usuario para gestionar el estado del usuario, la cual determina la posición del usuario en la cola de espera, así como otras propiedades necesarias para decidir acerca de la colocación en cola de espera vinculadas al usuario. Tradicionalmente, para una configuración de un único nombre de host y ruta de acceso, era muy sencillo definir simplemente la cookie como __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/es/product_123. Esto garantizaba que cuando se renovará la página nos enviaría la misma cookie de Waiting Room para que la analizáramos y actualizáramos. Sin embargo, dejó de ser sencillo cuando quisimos compartir la misma cookie en distintas combinaciones de subdominios o rutas de acceso, por ejemplo, en example.com/en/product_123.
Métodos para establecer varias cookies
Consideramos y evaluamos dos métodos para permitir el uso compartido de la cookie para la misma sala de espera.
El primer método que consideramos era emitir varios encabezados Set-Cookie en la respuesta HTTP. En el ejemplo multilingüe anterior, por ejemplo, podríamos añadir lo siguiente en el encabezado de la respuesta:
Set-Cookie: __cfwaitingroom=[cookie-value]…Domain=example.com; Path=/en/product_123 …
Set-Cookie: __cfwaitingroom=[cookie-value]...Domain=example.com; Path=/es/product_123 …
Este método nos permitiría gestionar los varios nombres de host y rutas de acceso para la misma sala de espera. Sin embargo, no se presenta como una solución escalable. La especificación RFC6265 no define ningún límite estricto, pero los navegadores aplican sus propios límites según cada implementación. Por ejemplo, Chrome permite que el encabezado de la respuesta tenga hasta 256 Kbytes antes de devolver un error ERR_RESPONSE_HEADERS_TOO_BIG para la transacción. Además, en este caso, el encabezado de la respuesta crecería proporcionalmente al número de combinaciones de nombres de host y rutas de acceso exclusivas, y estaríamos repitiendo de forma redundante el mismo valor de cookie N número de veces (donde N es el número de rutas adicionales). Aunque este enfoque nos habría permitido gestionar eficazmente una lista limitada de combinaciones de nombres de host y rutas de acceso que sería necesario establecer, no era idóneo para aquello casos donde se espera un número mayor de rutas para un sitio determinado.
El segundo enfoque que hemos considerado, y con el que decidimos seguir adelante, consistía en establecer la cookie en el dominio raíz (o el subdominio más habitual). En otras palabras, buscaríamos el subdominio más habitual en la lista de rutas y lo utilizaríamos como dominio. De la misma forma, en el caso de las rutas, esto implicaría determinar el prefijo menos habitual de la lista de rutas y utilizarlo como el valor que se debe establecer en el atributo path. Por ejemplo, considera una sala de espera con las siguientes dos rutas configuradas, a.example.com/shoes/product_123 y b.example.com/shoes/product_456.
Para determinar el dominio que se establecería para la cookie, podemos observar que example.com es el subdominio más habitual en la lista de dominios. Al aplicar el algoritmo de subdominio más habitual, obtendríamos example.com como subdominio. Al aplicar el algoritmo de prefijo menos habitual en el conjunto de rutas de acceso, /shoes/product_123 y /shoes/product_456, obtendríamos /shoes como ruta de acceso. Por lo tanto, el encabezado set-cookie sería el siguiente:
Set-Cookie: … __cfwaitingroom=[cookie-value]; Domain=example.com; Path=/shoes …
Ahora, cuando un visitante accede a cualquiera de las páginas cubiertas por esta sala de espera, podemos garantizar que Waiting Room recibe la cookie adecuada y que solo se habrá incluido Set-Cookie en el encabezado de la respuesta.
Sin embargo, aún no hemos terminado. Aunque podemos identificar el subdominio habitual (o dominio raíz) y el prefijo de ruta de acceso común, aún tendríamos un problema si las rutas desde una sala de espera se solaparan con las de otra sala de espera. Por ejemplo, supongamos que configuramos dos salas de espera para el mismo sitio donde vendemos nuestro calzado especial:
Sala de espera A
a.example.com/shoes/product_123
b.example.com/shoes/product_456
Sala de espera B
c.example.com/shoes/product_789
d.example.com/shoes/product_012
Si aplicamos el mismo algoritmo tal como hemos descrito anteriormente, se establecerían las mismas propiedades de dominio y ruta de acceso para ambas cookies. Para la sala de espera A, el dominio sería example.com y la ruta de acceso sería /shoes. De la misma forma, para la sala de espera B, el subdominio más habitual también sería example.com y el prefijo de ruta de acceso menos habitual sería be /shoes. Esto nos evitaría eficazmente distinguir ambas cookies y dirigiría al visitante a la sala de espera adecuada. Para resolver el problema del solapamiento de los nombres de cookie, hemos añadido el requisito de definir un sufijo personalizado exclusivo para la zona del cliente. Por este motivo, es necesario proporcionar un sufijo de cookie personalizado al configurar una sala de espera que cubra varios nombres de host y rutas de acceso. Por lo tanto, si se ha asignado a la sala de espera A el sufijo de cookie "a" y a la sala de espera B el sufijo de cookie "b", las dos definiciones de Set-Cookie serán las siguientes:
Sala de espera A
Set-Cookie: __cfwaitingroom_a=[cookie-value]; Domain=example.com; Path=/shoes
Sala de espera B
Set-Cookie: __cfwaitingroom_b=[cookie-value]; Domain=example.com; Path=/shoes
Cuando un visitante envía una solicitud a una página donde hay configuradas dos salas de espera distintas, Waiting Room puede distinguir y seleccionar la cookie correspondiente a esa solicitud específica y utilizarla para determinar qué ajustes de sala de espera son aplicables a ese usuario, en función de dónde se encuentre en el sitio.
Con la adición de la cobertura de varios host y rutas de acceso a Waiting Room, nos complace ofrecerte opciones para que puedas incorporar Waiting Room en tu sitio con mayor flexibilidad, proporcionando así a tus visitantes la mejor experiencia posible, al mismo tiempo que proteges tu sitio durante periodos de mucho tráfico. Asegúrate de que tu sitio esté siempre protegido contra los picos de tráfico. Prueba ya Waiting Room o ponte en contacto con nosotros para saber más sobre la versión Advanced de Waiting Room.