Resumen

  • HTTP Vary identifica campos de solicitud que pudieron influir en la representación elegida por el origen; una caché debe comparar esos campos antes de reutilizar la respuesta sin validación.
  • El campo no certifica la configuración desplegada, todos los criterios de la aplicación, la separación de inquilinos o autorizaciones, ni la huella de la representación que realmente se entregó.

Imaginemos una plataforma que publica configuración específica de cada inquilino bajo un URI compartido. El inquilino A solicita el recurso, el origen devuelve su marca y responde con Vary: Accept-Encoding. Un panel de garantías ve un campo Vary válido y marca el aislamiento en verde. Más tarde, el inquilino B usa la misma preferencia de codificación y recibe desde el borde los bytes de A.

Vary no falló. Describió la dimensión que el origen declaró para seleccionar aquella respuesta. El fallo consiste en convertir una declaración limitada en prueba de una frontera más amplia que nunca pretendió certificar.

Lo que Vary afirma

RFC 9110 define Vary como un campo de respuesta que describe qué partes de la solicitud, aparte del método y el URI objetivo, pudieron influir en la selección de contenido del servidor de origen. Cuando contiene nombres de campos, estos son los campos de selección. Es una declaración del origen sobre posibles entradas de selección para esa respuesta.

Tiene dos fines. Advierte a las cachés que no reutilicen la respuesta para una solicitud posterior si no coinciden los campos designados, salvo que el origen valide la reutilización. También indica al agente de usuario que hubo negociación de contenido y que otros valores podrían producir otra representación. Ningún fin convierte el encabezado en telemetría emitida por la caché que luego almacena o sirve la respuesta.

El comodín aclara aún más el límite. Vary: * significa que pudieron intervenir aspectos ajenos a los campos nombrados, incluso la dirección de red del cliente. El receptor no puede decidir si la respuesta sirve para otra solicitud basándose solo en sus campos y debe remitirla al origen. Un proxy no puede generar el comodín. Es una declaración de incertidumbre, no un interruptor universal de aislamiento.

La clave real es un hecho distinto

RFC 9111 llama clave de caché a la información que una caché usa para escoger una respuesta almacenada. Como mínimo incorpora el método y el URI objetivo. La caché puede añadir los campos designados por Vary y otros datos propios.

Cuando una respuesta almacenada incluye Vary, la caché no debe reutilizarla sin validación salvo que coincidan todos los campos designados con los de la solicitud que originó el almacenamiento. Solo puede normalizar diferencias cuando se conserva la semántica del campo. La ausencia de un campo designado solo coincide con otra ausencia. Una respuesta almacenada con Vary: * nunca coincide.

Son reglas firmes, pero no responden cuatro preguntas operativas. ¿La caché desplegada interpretó y aplicó el campo? ¿Algún intermediario lo eliminó o reescribió? ¿La aplicación eligió contenido según una entrada no declarada, como un inquilino resuelto después de autenticar? ¿El objeto entregado corresponde a la variante que la caché creyó seleccionar? Vary aporta evidencia, pero no contesta por sí solo.

El aislamiento puede depender de dimensiones invisibles

Una aplicación puede seleccionar contenido según una cuenta autenticada, un mapeo de inquilino, una cohorte funcional, una versión de política, una jurisdicción o una configuración de borde. Algunos datos viajan en la solicitud; otros proceden del estado del servidor. RFC 9110 permite Vary: * cuando intervienen factores externos al mensaje, pero esa señal impide la reutilización normal en vez de describir una partición privada reutilizable.

Por eso no se puede inferir aislamiento de la mera presencia de Vary ni de una lista limitada al idioma y la codificación. Un campo sintácticamente correcto puede omitir una dimensión de la lógica real. En sentido contrario, una caché puede añadir una partición de privacidad que Vary no muestra. La respuesta visible no revela ninguno de los dos resultados.

La separación también es distinta de la frescura. Una variante puede estar fresca y ser incorrecta porque falta una dimensión en la clave. Puede estar caducada pero dentro de la partición correcta. La revalidación puede confirmar la reutilización de una representación sin demostrar que la solicitud cayó en el inquilino adecuado. Frescura, validación, autorización y selección son controles relacionados, no equivalentes.

Evidencia para sostener la afirmación

Para afirmar que un despliegue mantuvo aisladas sus representaciones, hay que unir la declaración de protocolo con la acción real. Registre la instancia o cohorte de caché y su versión de configuración; método y URI; valor exacto de Vary recibido; valores normalizados y ausencia de cada campo designado; todas las dimensiones de selección de la aplicación; contexto de inquilino y autorización; decisión de acierto, miss de caché o revalidación; identidad del objeto almacenado; y un resumen criptográfico de los bytes servidos.

Este recibo de selección de variante es una síntesis editorial de evidencia, no un elemento de protocolo definido por el IETF. Evita convertir una señal normativa estrecha en una afirmación operativa más amplia. Debe conservar el punto de observación, porque el origen, una caché intermedia y el borde pueden ver campos distintos y aplicar configuraciones distintas.

Vary es útil cuando se respeta su alcance. Hace visible la negociación declarada e impone obligaciones concretas de comparación. El error de garantías empieza al tratar la declaración como prueba de implementación, aislamiento o resultado. El campo puede indicar dimensiones previstas; solo la configuración observada y la entrega muestran que la representación correcta quedó en el lado correcto de la frontera.

Fuentes