Resumen

  • No-Vary-Search deja que el origen indique claves de consulta o un orden que no cambian la equivalencia de una respuesta para la caché. El resto de las reglas de reutilización de HTTP sigue vigente.
  • La URL completa continúa en el navegador, la red y los registros. Una clasificación errónea puede omitir una llamada al origen y entregar contenido guardado bajo otro contexto de usuario.

Una tienda recibe /oferta?producto=9&campana=correo. Más tarde llega /oferta?campana=social&producto=9. El equipo de aplicación sabe que campana no cambia ni una línea de la ficha. Para una caché que solo observa los destinos, las URL son distintas, y ese desconocimiento es una propiedad de seguridad, no una torpeza.

El documento draft-ietf-httpbis-no-vary-search-09, fechado el 17 de agosto de 2026, propone una declaración explícita. A 29 de agosto sigue siendo un Internet-Draft activo de HTTPBIS, con destino de Proposed Standard y estado de aprobación pendiente de anuncio y seguimiento del Area Director. Aún no es un RFC ni figura No-Vary-Search en el registro IANA de nombres de campos HTTP.

La versión importa porque el despliegue ocurre antes que la certeza institucional. La especificación actual aporta gramática y límites examinables. No certifica que una plataforma la implemente, que el origen haya entendido todas sus claves o que un porcentaje de aciertos sea seguro.

HTTP parte de la separación exacta

RFC 9111 exige que una respuesta almacenada cumpla varias condiciones antes de resolver una solicitud: método, URI de destino, campos señalados por Vary, frescura o validación y directivas de control. Una consulta distinta produce normalmente una URI distinta.

La caché no debe adivinar que session, route o utm_medium es decorativo. El mismo cuerpo en una muestra tampoco demuestra que la clave no afecte autorización, contabilización o una respuesta futura. Solo la capa que conoce la aplicación puede clasificarla.

El nuevo campo amplía la coincidencia de URI y nada más. No anula Vary, no renueva una respuesta caducada, no convierte contenido privado en público y no concede acceso. Una vez hallada la equivalencia de consulta, cada condición restante de RFC 9111 todavía debe superarse.

Tres claves y una asignación de autoridad

El valor sigue el Diccionario de RFC 9651. key-order expresa si el orden de las claves carece de importancia. params enumera nombres que se ignoran. except formula la política inversa: únicamente las claves de su lista siguen variando. params y except son incompatibles.

El origen coloca el campo. Un intermediario no puede insertarlo, borrarlo ni modificarlo salvo que actúe como origen de esa respuesta. Esa regla impide que una optimización del borde se transforme silenciosamente en una definición de identidad de la aplicación.

Un valor ausente, mal formado o contradictorio vuelve a la configuración predeterminada: consulta exacta y orden significativo. El castigo es perder aciertos, no perder aislamiento. Las claves desconocidas del diccionario se ignoran. Por eso una ampliación futura solo podrá sumar equivalencias; si quisiera restringirlas tendría que utilizar otro campo para que implementaciones antiguas no reutilicen en exceso.

El algoritmo ve pares, no una cadena opaca

La equivalencia nunca atraviesa esquema, host, puerto o ruta. Dentro de esa frontera, una política no predeterminada analiza la consulta con el modelo application/x-www-form-urlencoded de WHATWG. Elimina los pares ignorados o conserva los incluidos en except, puede ordenar por clave y compara claves y valores; los duplicados no desaparecen.

La decodificación porcentual y la conversión de + a espacio hacen equivalentes cadenas que no lucen iguales. Secuencias UTF-8 inválidas pueden terminar en U+FFFD y colapsar bytes distintos en una misma clave. No hay normalización Unicode: representaciones NFC y NFD siguen separadas.

El problema aparece cuando una firma cubre los bytes originales, el router lee el primer duplicado o un valor vacío activa consentimiento. El borrador desaconseja el mecanismo si la consulta no sigue el modelo form-urlencoded. RFC 6943 advierte de la comparación de identificadores entre dominios con normalizaciones distintas; aquí el falso positivo decide qué cuerpo se entrega.

La declaración habilita; la caché decide

Una caché compatible puede aplicar la comparación, pero no tiene obligación de hacerlo. Puede buscar primero la URI exacta, indexar otra clave simplificada o rechazar el acierto. El origen aporta conocimiento, mientras que la caché conserva la decisión local porque soporta la consecuencia de reutilizar.

Si respuestas del mismo host y ruta contienen configuraciones no vacías en conflicto, el borrador permite preferir la asociada con un Date más reciente. Es una regla de convergencia, no evidencia de corrección. Una mala política puede ser la última y propagarse de manera desigual.

Tampoco cambia la invalidación. Después de una operación que modifica estado, la caché puede invalidar URI equivalentes, pero no está obligada a ampliar el conjunto. Dos entradas iguales al leer pueden quedar desalineadas al escribir. Una clave añadida para “romper caché” pierde su efecto si fue declarada irrelevante; una ruta o nombre direccionado por contenido mantiene una semántica distinta.

El identificador sigue viajando

No-Vary-Search no limpia la dirección. El navegador la muestra y guarda; el CDN y los proxies la reciben; los registros y la analítica pueden conservarla. Una caché privada quizá evite que el origen procese una segunda etiqueta. Una caché compartida sigue observándola y, además, puede entregar un mismo objeto a más solicitudes.

Nunca deben ignorarse parámetros que controlen identidad, autorización, firmas, consentimiento, rutas, auditoría, revocación, facturación o cualquier proceso necesario para una reutilización segura. Que un byte no cambie la imagen no significa que carezca de función. Un token de un solo uso puede gobernar el derecho a obtener un objeto idéntico; un código de atribución puede sostener una obligación aunque el HTML sea igual.

El peor error de una caché compartida entrega a una persona una representación capturada para otra. Los controles private y la partición correcta siguen siendo barreras, pero no convierten una equivalencia falsa en aceptable. El origen responde por la clasificación; la caché, por la separación efectiva.

La ausencia del origen también debe dejar evidencia

Un expediente útil registra la URL solicitada, la URL almacenada, el campo original, el diccionario analizado, los pares comparados, la entrada elegida, las demás comprobaciones de RFC 9111, el contexto de usuario y partición, el hit o miss, el bypass del origen y la huella del cuerpo servido. Sin esos datos, una mayor tasa de aciertos puede ocultar una fuga más eficiente.

La idea de Lu Heng de una especificación común mínima encaja con esta división. La gramática común es pequeña; la aplicación decide localmente qué significa su consulta; cada caché adopta voluntariamente. La primacía del código en ejecución exige comprobar la selección real y el resultado, no limitarse a inspeccionar una configuración.

Su distinción entre soberanía técnica y práctica de los datos completa el mapa. El origen controla formalmente el encabezado, pero navegador, CDN y caché conservan copias y decisiones; incluso puede que el origen no vea la solicitud resuelta. El gobierno debe seguir esas custodias reales.

La asimetría segura es deliberada: la incertidumbre produce un miss. Nunca debe producir una separación menor.