Cloudflare ha puesto a disposición de los usuarios ordinarios a Vary por fin, y la compañía se apresura a difundir la noticia. La función coloca el control sobre el encabezado más confuso de HTTP directamente en manos de los clientes. En lugar de permitir que Vary rompa su caché, ahora puede instruir a Cloudflare qué variaciones son realmente importantes.
El anuncio viene con una advertencia. Vary es «la parte más fea de HTTP que aún no hemos mejorado», según una publicación, y tiene «una interoperabilidad bastante pésima» entre intermediarios. Ahí es donde los ingenieros sensatos suelen retroceder lentamente con las manos en alto. Pero Cloudflare no está retrocediendo. La compañía ha construido un sistema que permite a los clientes decidir cuánta variación es significativa para la caché, en lugar de quedarse con lo que declara el origen.
Lo que Vary Hace Realmente
El encabezado Vary es un encabezado de respuesta HTTP que instruye a las cachés intermediarias, como Cloudflare, qué campos de solicitud pueden influir en la respuesta emitida por el servidor de origen. Un servidor podría entregar varios formatos de imagen a diferentes navegadores, o servir idiomas distintos desde la misma URL. Si una caché descuida Vary, corre el riesgo de enviar los bytes incorrectos a una solicitud. Sin embargo, si considera cada valor de encabezado sin procesar como separado, un pequeño número de solicitudes relacionadas puede expandirse a miles de entradas de caché apenas reutilizables.
Un encabezado es fácil de explicar pero difícil de manejar. La fuente identifica los encabezados de solicitud que podrían influir en una respuesta, mientras usted elige cómo Cloudflare los maneja. Puede estandarizar encabezados de negociación conocidos, enviar valores exactos cuando esas pequeñas diferencias cuentan, o evitar la caché cuando la variación resulta demasiado impredecible.
El Problema Central
El problema comienza con las limitaciones del encabezado. Señala qué campos de solicitud podrían influir en una respuesta, pero no dice qué cambios reales son importantes. Esa brecha es exactamente lo que dificulta las cosas.
Supongamos que una sola URL puede producir dos versiones distintas y válidas de una página web. Cuando un navegador la solicita,
GET /catalog HTTP/1.1
Host: example.com
Accept: text/html
HTML es devuelto por el origen, y Accept es identificado como un campo cuya presencia puede influir en la respuesta.
La respuesta comienza con una línea de estado HTTP que anuncia una solicitud exitosa: HTTP/1.1 200 OK. Debajo de ella, aparece un encabezado de contenido que especifica el tipo de documento, seguido por una directiva de caché que establece una edad máxima pública de 3600 segundos. El encabezado final, Vary: Accept, indica que la respuesta del servidor puede variar dependiendo de lo que el cliente acepte.
Cuando un cliente de API envía una solicitud a la misma URL, puede especificar una preferencia diferente.
GET /catalog HTTP/1.1
Host: example.com
Accept: application/json
Esta vez, la respuesta correcta es JSON. El encabezado Vary: Accept indica que la caché no debe depender únicamente de la URL para seleccionar una respuesta; también debe tener en cuenta el valor Accept de la solicitud.
Sin Vary, la primera respuesta que entre en la caché puede ser servida a ambos clientes, independientemente de cuál sea. Si HTML llega antes que JSON, entonces el cliente de la API recibe marcado y su analizador JSON falla. Si JSON llega primero en cambio, un navegador que espera una página web recibe una respuesta de la API. Vary impide que la caché sirva la respuesta incorrecta al cliente solicitante. Aún así, plantea una pregunta más difícil: cuando dos solicitudes llevan diferentes valores de encabezado, ¿realmente necesitan respuestas separadas?
Cuando el Almacenamiento en Caché Correcto Se Vuelve Inútil
Una situación se vuelve más complicada cuando una respuesta cambia a través de varios campos a la vez. Considere un origen que ofrece contenido en solo tres idiomas — inglés, francés y alemán — e imagine qué sucede cuando un cliente envía una solicitud que pide información en más de uno de esos campos al mismo tiempo.
Accept-Language: en-US, fr;q=0.8
Mientras que otro cliente podría solicitar:
Accept-Language: fr;q=0.8, en-GB
Las dos solicitudes piden el mismo idioma, pero el servidor las trata como distintas, almacenando cada una como su propia versión a pesar del contenido coincidente. Esto sucede porque cada solicitud lleva su propio tag de orden e idioma, y el servidor no puede distinguir estos por sí solo. Entonces, dos respuestas idénticas pueden terminar almacenadas como variantes separadas en la caché.
El problema central con Vary es que las aplicaciones frecuentemente crean un número limitado de formatos de salida a partir de una gran variedad de posibles solicitudes de entrada. El sistema de origen reconoce que muchas preferencias de usuario para el idioma se reducen a solo tres opciones admitidas, mientras que una caché generalmente carece de ese contexto.
Un caché puede resultar perfectamente preciso pero casi perpetuamente frío. Respuestas similares pueden distribuirse a través de entradas que reciben demasiado poco tráfico para mantenerse calientes y en caché. Estas pueden ocupar espacio, desplazarse mutuamente, reducir las tasas de éxito y forzar más llamadas a los servidores de origen. Si bien la eliminación elimina las entradas frías, no ofrece ninguna forma de combinarlas simplemente porque sus respuestas coinciden.
Un estudio basado en más de 120 millones de respuestas de casi 50.000 sitios web conocidos descubrió que casi 3.000 de ellos difieren en cuatro o más categorías. Otros cambiaron en solo 10, 23 o hasta 47 categorías. La firma tiene como objetivo garantizar que los usuarios tengan los medios para aplicar Vary apropiadamente, sin construir un exceso de almacenamiento innecesario.
Variación de Alta Cardinalidad Es Deliberada
Ciertos cambios son intencionales. Las redes de distribución de contenido y los proxies inversos pueden agregar valores, incluyendo una región geográfica, para organizar el contenido sistemáticamente. Este enfoque tiene éxito cuando los valores potenciales son limitados y todos los componentes comparten la misma comprensión de lo que significan. De lo contrario, el caché se desintegra en variantes que podrían nunca volver a utilizarse.
Cómo las Reglas de Caché Controlan Vary
Hasta hoy, los clientes de Cloudflare tenían varios enfoques para tratar el contenido que necesitaba manejo negociado, algo parecido a lo que hace Vary. Podían optar por omitir el caché por completo y dejar que su servidor de origen administrara la negociación directamente. También podían construir una clave de caché personalizada o aplicar otra regla que imite la lógica de negociación del origen. Un Worker era otra opción, o podían aprovechar funciones como Vary para imágenes. Todos estos métodos todavía funcionan, pero cada uno tiene compensaciones: algunos renuncián al almacenamiento en caché por completo, algunos requieren duplicar la lógica de la aplicación, algunos exigen escribir código adicional y otros cubren solo un conjunto más limitado de casos.
Este método revisado de Reglas de Caché mantiene suficiente variedad para entregar la respuesta correcta mientras impide que las pequeñas diferencias entre las solicitudes arruinen el rendimiento del caché. El origen continúa identificando qué encabezados de solicitud pueden influir en una respuesta, pero usted determina cuánto varía realmente para el caché.
Los Números Detrás del Problema
- Más de 120 millones de respuestas analizadas de casi 50,000 sitios populares.
- Casi 3,000 sitios varían en cuatro o más campos.
- Algunos variaban en 10, 23, o incluso 47 campos.
- Los encabezados reales pueden tener una cardinalidad mucho mayor: los valores de User-Agent son numerosos, las cookies pueden ser únicas para visitantes individuales y los encabezados de preferencia pueden diferir en ordenación, formato (¡importan los espacios y las tabulaciones!) y valores de calidad.
Comparación de Enfoques de Manejo de Vary
| Enfoque | Qué Hace | Intercambio |
|---|---|---|
| Evita la caché | Permite que el origen gestione la negociación | Renuncia por completo al almacenamiento en caché |
| Clave de caché personalizada | Reproducir la lógica de origen en una regla. | Duplica la lógica de aplicación. |
| Utilizar un Worker. | Manejar la variación programáticamente. | Requiere código adicional. |
| Nuevas Reglas de Caché. | Decidir qué variación importa. | Preserva la eficiencia de la caché. |
Lo que los Clientes Pueden Hacer Ahora.
Cada plan ahora admite la función, que le permite indicar qué puede cambiar en la fuente y luego establecer su propio límite sobre cuánto importa la diferencia para la copia almacenada. Va más allá de lo que era posible antes.
La empresa ha creado un método que permite a los usuarios decidir qué versiones importan y cuáles son simplemente ruido de fondo estático. Cloudflare ahora está presentando ese remedio ante su audiencia, al tiempo que ofrece una explicación del problema en sí.
La función ya está disponible. Los sitios que utilizan Vary deberían ponerla a prueba, ya que la otra opción es una caché que funciona correctamente pero nunca entrega ni un solo elemento.
El análisis se basa en más de 120 millones de respuestas recopiladas de casi 50,000 sitios populares, con más de 3,000 de esos sitios variando en cuatro o más campos. Algunos sitios diferían en solo 10, mientras que otros variaban en 23, o incluso hasta 47 campos. Los datos están disponibles en todos los planes.
Una solución a lo que antes era la parte más fea de HTTP ahora existe, y si la implementa depende de su sitio particular.
Material de origen: “Acabamos de lanzar soporte para la parte más fea de HTTP: Vary,” cloudflare.com.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.