Entrevista frontend: ¿Cómo implementarías de forma segura un canary de Compression Dictionary Transport?

Planteamiento y contexto

Un sitio de documentación genera HTML, CSS y JavaScript similares en cada lanzamiento. El equipo desea que las respuestas posteriores reutilicen una respuesta anterior como diccionario de Brotli o Zstandard para reducir los bytes repetidos, pero el soporte de los navegadores no es uniforme y algunas respuestas contienen datos privados de los usuarios. Diseña un plan de canary, caché y seguridad utilizando Compression Dictionary Transport.

El RFC 9842 define un flujo en el que una respuesta anuncia un diccionario con Use-As-Dictionary, un cliente ofrece un diccionario disponible con Available-Dictionary y ambas partes negocian una codificación de contenido basada en diccionarios. La especificación exige contextos seguros HTTPS; MDN actualmente clasifica la funcionalidad como de disponibilidad limitada (Limited availability), por lo que no puede ser una ruta obligatoria para todos los navegadores.

Lo que evalúa el entrevistador

• ¿Puedes explicar el registro del diccionario, la coincidencia, la negociación de hashes, la elección de la codificación y el fallback a compresión ordinaria?
• ¿Puedes manejar la frescura, las claves de caché, las versiones de lanzamiento, las CDN y la consistencia entre nodos?
• ¿Puedes reconocer los riesgos de inferencia de contenido o canales laterales de compresión derivados del uso de diccionarios compartidos?
• ¿Puedes diseñar una mejora progresiva considerando la capacidad del navegador, HTTPS y la legibilidad de las respuestas?
• ¿Puedes demostrar el ahorro de bytes sin incrementar los errores ni la exposición de la privacidad?

Preguntas para clarificar primero

• ¿Soportan los navegadores objetivo, WebViews, proxies y la CDN las codificaciones de diccionario pertinentes? ¿Puede el despliegue limitarse únicamente a Chromium?
• ¿Cuáles respuestas son públicas, del mismo origen y repetitivas, y cuáles contienen datos de usuario, de inquilino (tenant) o de autorización?
• ¿Quién crea, firma, expira y revierte los diccionarios, y están las versiones de lanzamiento vinculadas a los hashes de los recursos?
• ¿Están las cachés separadas por idioma, inquilino, estado de autorización y codificación de contenido?
• ¿Utiliza ya el sitio Brotli, Zstandard, ETag, Early Hints o almacenamiento en caché con service workers?

Respuesta en 30 segundos

"Seleccionaría recursos públicos, del mismo origen y altamente repetitivos según la capacidad del navegador y la sensibilidad de los datos. A través de HTTPS, el servidor anuncia un diccionario versionado con Use-As-Dictionary; tras recibir Available-Dictionary, elige dcb, dcz o Brotli/gzip ordinario. Las versiones de los diccionarios y del contenido, los hashes y las variantes de caché se mantienen aislados, y las respuestas sensibles no comparten diccionarios. Realizaría un canary con Chromium y un conjunto pequeño de recursos, mediría bytes, errores de decodificación, aciertos de caché y alertas de privacidad, y recurriría a la codificación ordinaria siempre que falle el soporte o la validación".

Análisis detallado paso a paso

1. Seleccionar los recursos adecuados. Comienza con recursos estáticos, públicos, del mismo origen y con versiones estables. Excluye HTML personalizado, datos de cuentas, respuestas entre inquilinos y secretos. Mide la repetición y el beneficio del diccionario antes de asumir la complejidad adicional.

1. Construir el flujo de negociación. Una respuesta utiliza Use-As-Dictionary para declarar una coincidencia, tipo, identificador y frescura. Un cliente con una coincidencia envía un hash en Available-Dictionary y anuncia las codificaciones de diccionario en Accept-Encoding. El servidor devuelve dcb o dcz únicamente cuando ambas partes lo soportan y el diccionario es reciente; de lo contrario, utiliza codificación ordinaria.

HTTP/2 200
Content-Type: text/javascript
Cache-Control: public, max-age=3600
Use-As-Dictionary: match="/assets/*", id="docs-v42", type="dictionary"

HTTP/2 200
Content-Encoding: dcb
Vary: Accept-Encoding, Available-Dictionary

1. Fijar el límite de consistencia. El ID del diccionario, la versión del recurso y el hash del contenido pertenecen a un único artefacto de lanzamiento. Cada nodo de la CDN debe obtener el mismo diccionario; no puede ocurrir que la mitad de los nodos devuelva un diccionario antiguo mientras el resto utiliza una nueva codificación. Vary y las claves de caché deben cubrir los encabezados de solicitud que modifican la representación, evitando que una respuesta basada en diccionario llegue a un cliente no compatible.

1. Gestionar la frescura y la reversión. Cuando un diccionario expira, se revoca o ya no coincide con la versión del contenido, deja de anunciarlo y recurre a la compresión ordinaria. Mantén los diccionarios antiguos durante una ventana de superposición controlada con un tiempo de retiro estricto. La reversión debe eliminar el anuncio, purgar las variantes de la CDN y restaurar Brotli/gzip; no debe depender de que los clientes limpien sus cachés.

1. Aislar el riesgo de privacidad. Protege el contenido del diccionario como recursos públicos del mismo origen. Si un atacante controla parte de la entrada y puede observar los tamaños comprimidos, las subcadenas repetidas podrían revelar contenido del diccionario o de la respuesta. Mantén los secretos fuera del mismo contexto de compresión que el texto controlado por un atacante y deshabilita la compresión por diccionario cuando sea necesario. HTTPS protege el transporte, pero no elimina los canales laterales de compresión.

1. Utilizar mejora progresiva. Ante un fallo de capacidad o negociación, se continúa con Brotli, gzip o una respuesta sin comprimir. Comienza con un pequeño grupo de recursos estáticos y navegadores. Compara la distribución de Content-Encoding, los bytes transferidos, el TTFB, los errores de decodificación, los aciertos de caché y la tasa de fallback; retira la funcionalidad si las ganancias no son estables.

Respuesta modelo

Limitaría el primer despliegue a recursos estáticos versionados, públicos y del mismo origen con alta repetición, excluyendo HTML personalizado, datos de inquilinos y secretos. A través de HTTPS, el servidor anuncia un diccionario con un ID, alcance de coincidencia y expiración mediante Use-As-Dictionary. Solo después de que el cliente envíe Available-Dictionary y negocie Accept-Encoding, el servidor devolvería dcb o dcz; los clientes no compatibles, los diccionarios obsoletos y las discrepancias de hash utilizan Brotli/gzip ordinario.

El artefacto de lanzamiento incluiría el diccionario, los hashes de los recursos y las variantes de caché de la CDN para que cada nodo sea consistente. Vary aísla la codificación y los encabezados de solicitud del diccionario. Nunca situaría entradas controladas por atacantes y secretos en el mismo contexto de compresión; HTTPS no elimina los canales laterales basados en tamaño. El canary comienza con Chromium y un conjunto estático reducido, midiendo bytes ahorrados, aciertos de caché, errores de decodificación, fallbacks y alertas de privacidad. Una reversión elimina el anuncio del diccionario y restaura la codificación ordinaria.

Errores comunes

• Síntoma: Habilitar diccionarios compartidos para cada respuesta → Por qué falla: Los datos personalizados o sensibles ingresan en un contexto de compresión inferible → Solución: Utilizar solo recursos estáticos públicos y compresión ordinaria para respuestas sensibles.
• Síntoma: Verificar únicamente Accept-Encoding e ignorar el hash y la frescura del diccionario → Por qué falla: El cliente podría usar el diccionario incorrecto o fallar al decodificar → Solución: Vincular ID, hash, versión y expiración.
• Síntoma: Almacenar en caché solo por URL en la CDN → Por qué falla: Una respuesta con diccionario podría llegar a un cliente no compatible → Solución: Separar la codificación, los encabezados del diccionario y las versiones de recursos mediante Vary y claves de caché.
• Síntoma: Tratar a HTTPS como la garantía de seguridad completa → Por qué falla: Los canales laterales de compresión aún pueden revelar subcadenas repetidas → Solución: Aislar la entrada controlada por atacantes de los secretos y deshabilitar la compresión por diccionario cuando sea necesario.

Preguntas de seguimiento y respuestas

¿Qué sucede cuando un navegador no lo soporta?

El servidor devuelve dcb o dcz únicamente tras una negociación exitosa del diccionario. Otras solicitudes continúan con Brotli, gzip o sin compresión; monitorea el fallback y nunca exijas una actualización para acceder a la página.

¿Cuánto tiempo debe vivir un diccionario?

Establece la vida útil a partir de la frecuencia de lanzamientos, el beneficio de la repetición y la velocidad de revocación, y codifica la elección en la política de lanzamientos. Utiliza una breve superposición durante los cambios de versiones estáticas, luego retira el diccionario antiguo y purga las variantes de la CDN en lugar de conservarlo indefinidamente.

¿Cómo pruebas la correcta decodificación y el almacenamiento en caché?

Prueba navegadores compatibles y no compatibles, HTTP/1.1, HTTP/2, diferentes nodos de la CDN, y cachés frías y calientes. Verifica Vary, hashes de contenido, bytes decodificados, respuestas 304, solicitudes al origen y el fallback a codificación ordinaria, no solo la tasa de compresión.

¿Qué señales harían que lo deshabilites de inmediato?

La mezcla de contenido entre usuarios, discrepancias de hash del diccionario, errores de decodificación, envenenamiento de caché, tamaños comprimidos anómalos o alertas de escaneos de privacidad deben provocar la eliminación inmediata de Use-As-Dictionary. Restaura la codificación ordinaria y preserva las métricas del incidente.

Fuentes

• Compression Dictionary Transport (RFC 9842)
• MDN Compression Dictionary Transport
• Chrome for Developers: Mejora de Google Search con diccionarios de compresión
• Documentación de Compression Dictionary Transport en Chromium

Lista de verificación para la entrevista

Comienza con la selección de recursos estáticos públicos y los encabezados de negociación. Luego cubre versiones de diccionarios, claves de caché, HTTPS, canales laterales, mejora progresiva y reversión. Valida el beneficio con métricas de bytes, caché y errores.

Conclusión en una frase

Los diccionarios compartidos reducen los bytes repetidos únicamente cuando el aislamiento de recursos, los hashes de versión, el fallback del navegador y las barreras de privacidad están plenamente implementados.