Resumen

  • El borrador activo de No-Vary-Search permite que las cachés compatibles ignoren determinadas diferencias de consulta al buscar una respuesta reutilizable. No sustituye la frescura, la autorización ni la negociación de contenido, y tampoco demuestra que las decisiones del cliente sean equivalentes.
  • Chrome documenta un cambio de contexto: la página prerenderizada ve primero su URL de preparación y recibe la URL final cuando se activa una navegación equivalente. El estado que depende de los parámetros debe vincularse o actualizarse entonces; cambiar la dirección visible no demuestra que hayan cambiado el modelo o el destino de una acción.

Un catálogo entrega la misma estructura HTML para dos productos. El identificador de la consulta sirve después para obtener los datos de cada ficha. Antes de que el lector haga clic, el navegador prepara una página. Durante el prerenderizado, el cliente lee el primer identificador y lo guarda. Finalmente, el lector elige el segundo producto. El navegador considera reutilizable la estructura preparada, la activa y sustituye la URL por la dirección elegida.

La dirección ya es correcta. ¿También lo es la decisión de la aplicación?

La igualdad del HTML inicial puede ser cierta mientras un modelo, una medición o el destino de una operación conserva el identificador anterior. Una variable capturada no se vuelve actual por el mero cambio de la barra de direcciones. Este es un supuesto analítico de diseño, no un incidente atribuido a Chrome ni un fallo observado en un cliente.

No-Vary-Search hace visible una distinción que conviene mantener pequeña y precisa. El mecanismo puede justificar que una diferencia de consulta no requiera otra respuesta del servidor. No puede justificar por sí solo que todas las decisiones tomadas durante la preparación sigan siendo adecuadas después de la elección real. Convertir ambas cosas en «la misma página» amplía una optimización hasta un ámbito que no puede certificar.

Lo equivalente es la respuesta, no toda la elección

A la fecha de esta investigación, draft-ietf-httpbis-no-vary-search-09 es la versión más reciente del Internet-Draft activo del grupo HTTPBIS. El texto de agosto de 2026 caduca el 18 de febrero de 2027. Datatracker lo muestra presentado para publicación y en el estado «Approved-announcement to be sent::AD Followup», con Proposed Standard como estatus RFC previsto. El proceso de aprobación ha avanzado: no sería correcto describirlo como una propuesta individual sin aprobación. Tampoco se presenta aquí como un RFC ya publicado.

El campo propuesto es un diccionario de Structured Fields. La lista params nombra los parámetros cuyas diferencias pueden ignorarse. La lista except conserva como significativos los parámetros indicados e ignora los demás. No pueden coexistir ambas entradas. key-order trata la importancia del orden de los nombres de parámetros. Una forma reconocida pero inválida devuelve la configuración de variación predeterminada, no un permiso silencioso para ignorarlo todo.

El contrato no elimina la información de la URL. Añade una forma de comparar identificadores a efectos de caché. El origen establece el campo; los intermediarios no deben insertarlo, quitarlo ni modificarlo salvo que actúen como origen de esa respuesta. La caché debe implementar la extensión para que tenga efecto. Ver el encabezado no prueba que cualquier navegador, CDN o proxy lo utilice.

Siguen vigentes las demás condiciones. RFC 9111 regula si una respuesta puede almacenarse y durante cuánto tiempo permanece fresca. La negociación de contenido y Vary también intervienen. Una coincidencia bajo No-Vary-Search no autoriza compartir una respuesta personal con otro usuario ni reutilizarla indefinidamente. La afirmación se refiere a diferencias de consulta que no alteran semánticamente la respuesta servida, dentro del resto del contrato HTTP.

Un identificador de producto puede ser irrelevante para una estructura común y esencial para un documento donde el servidor ya incluyó los datos de la ficha. Un parámetro de campaña puede no modificar nada en una aplicación y seleccionar contenido distinto en otra. Su nombre no decide el caso. El origen necesita pruebas sobre la respuesta concreta, no una clasificación cómoda de parámetros «de seguimiento» o «solo del cliente».

Preparar una respuesta no es preparar una página en ejecución

La documentación oficial de Chrome describe el ciclo de vida. No-Vary-Search puede utilizarse en navegaciones especulativas con precarga y prerenderizado. En el segundo caso, la página observa inicialmente la URL utilizada para prepararla. Si el clic final cambia únicamente parámetros cubiertos, Chrome puede activar la página ya preparada y sustituir su dirección por la URL final.

La documentación advierte que el JavaScript dependiente de parámetros debe ejecutarse después de la activación. También señala que el contenido generado por el cliente puede requerir una actualización entonces. Su ejemplo distingue un HTML inicial común de los datos específicos que JavaScript obtiene para cada producto. Es un comportamiento documentado de Chrome, no una declaración de compatibilidad universal.

Por eso conviene separar tres poblaciones en las pruebas: navegación ordinaria, reutilización mediante precarga y activación de una página prerenderizada. Precargar obtiene o prepara una respuesta; prerenderizar puede preparar una página que ejecute código antes de volverse activa. El problema de un identificador capturado demasiado pronto corresponde a ese último ciclo, no a cualquier descarga anticipada.

La indicación expects_no_vary_search en las reglas de especulación tampoco demuestra que la aplicación sea correcta. Expresa una expectativa sobre el encabezado y puede ayudar a evitar trabajo innecesario. La respuesta real sigue dependiendo del contrato del origen. Ni esa indicación ni una descarga especulativa exitosa prueban que el modelo o un formulario respeten la consulta finalmente seleccionada.

La transición debe tener un responsable y un significado claro. El estado derivado de la navegación prevista es provisional. Cuando la página se activa, la aplicación identifica los parámetros finales, los vincula con el estado pertinente y actualiza sus consecuencias. Corregir el título pero dejar el destino de una acción en el producto anterior no completa la transición. Obtener datos nuevos y mantener una atribución antigua tampoco.

La activación identifica una navegación; no concede todos los permisos

La prueba útil prepara una consulta admisible y activa otra. Después inspecciona el registro seleccionado, lo que se presenta y aquello a lo que apunta una acción iniciada por el usuario. No basta con mirar la dirección. Debe verificarse si la elección final llegó a cada parte dependiente o si solo cambió una etiqueta sobre un modelo anterior.

No todo el trabajo tiene que esperar al clic. La estructura común, los recursos compartidos y la preparación verdaderamente independiente de la consulta siguen ofreciendo valor. La frontera está entre hacer trabajo temprano y tratar una hipótesis temprana como la elección definitiva del lector. Puede prepararse una posibilidad sin concederle todavía autoridad para dirigir la operación posterior.

La propia activación tampoco equivale a consentimiento general. Determina qué navegación se hizo efectiva. La autenticación, los derechos de acceso y la autorización de una acción con consecuencias externas siguen siendo requisitos distintos. Usar el identificador correcto es necesario para muchas decisiones, pero no permite cualquier uso de ese identificador. Llegar a una página no es ordenar una divulgación ni una instrucción externa.

El borrador impone además una limitación en el servidor. El origen no debe declarar insignificante un parámetro si eso evita procesamiento necesario para reutilizar la respuesta con seguridad. La versión 09 enumera autorización, identificación del usuario, verificación de firma, consentimiento, enrutamiento, auditoría y revocación. Una buena actualización al activar no puede reparar una respuesta que nunca fue segura para reutilizar.

En una caché compartida, ignorar por error el parámetro que selecciona datos personales puede servir a otro usuario una respuesta que no le corresponde. La seguridad de la respuesta y la disciplina del cliente son controles complementarios. Uno limita lo que puede compartirse; el otro vincula las decisiones con la navegación real. La rapidez de carga no demuestra que ambos estén presentes.

La comparación debe respetar la consulta, no una intuición sobre ella

No-Vary-Search utiliza el análisis application/x-www-form-urlencoded y las convenciones WHATWG. No invita a quitar subcadenas arbitrarias. La configuración predeterminada compara la consulta de forma exacta. Una configuración distinta introduce el análisis en pares, el filtrado de los parámetros pertinentes y, cuando corresponde, la ordenación estable por nombre antes de comparar claves y valores.

Los casos de codificación y valores repetidos merecen pruebas negativas. Los signos más y los escapes porcentuales pueden influir en el resultado del análisis. Ignorar el orden de los nombres no permite reordenar libremente los valores del mismo nombre. No se aplica normalización Unicode. El borrador también advierte de falsos positivos cuando una decodificación UTF-8 con pérdida aproxima secuencias distintas. No deben apoyarse decisiones de seguridad en que una secuencia inválida siga siendo distinguible tras el análisis.

No es necesario convertir cada caso del analizador en una decisión central de dirección. Sí es necesario exigir la comparación correcta y pruebas que ataquen las diferencias importantes de la aplicación. Las decisiones locales sobre parámetros pueden variar según la respuesta; la semántica de la comparación no puede sustituirse por la impresión de que dos direcciones «se parecen».

Los parámetros evolucionan mientras las respuestas antiguas siguen almacenadas

La frontera de activación también tiene una dimensión de versión. Un parámetro sin efecto en la estructura actual puede adquirir significado en una actualización. Una política except que conserva unos pocos nombres ignora además los nuevos que aparezcan. Una política params estrecha deja significativos los nombres no incluidos. Ninguna estrategia es siempre correcta, pero distribuyen de manera distinta la responsabilidad por cambios futuros.

La propuesta de gobernanza es revisar la equivalencia cuando cambian el significado de los parámetros, la respuesta del servidor o el momento en que el cliente los lee. Relacionar la decisión con una versión y un responsable permite identificar la hipótesis que debe retirarse. Es especialmente útil enfrentar una respuesta antigua almacenada con las nuevas navegaciones, no probar solo un encabezado nuevo sobre un documento nuevo. Esta recomendación es análisis del autor, no un campo adicional exigido por IETF.

Modificar el encabezado del origen no reescribe retrospectivamente todos los objetos de las cachés. El borrador utiliza la configuración de la respuesta almacenada y permite estrategias que prefieren información de política más reciente cuando hay conflicto. No promete la retirada instantánea de una equivalencia anterior en todas partes. Tampoco cambia las exigencias de invalidación: invalidar URI conceptualmente equivalentes está permitido, pero no es obligatorio.

En consecuencia, una petición que cambia estado puede dejar variantes equivalentes sin invalidar. Hacer variar un parámetro para forzar una respuesta nueva puede no servir si la política almacenada ignora ese parámetro. Una transición necesita validación, invalidación o un espacio de recursos distinto adecuado al despliegue, no la suposición universal de que una nueva consulta siempre provoca trabajo nuevo. La elección depende de la caché y del despliegue y debe comprobarse sobre las respuestas antiguas que todavía pueden reutilizarse.

La decisión futura debe permanecer donde se conoce la elección final

Las notas de heng.lu sobre especificación inicial mínima, decisión futura localizada y adopción voluntaria ayudan a delimitar el contrato. No se trata de centralizar todas las selecciones de producto ni de prohibir la preparación especulativa. Se trata de declarar qué puede compartirse y dónde una elección posterior sigue perteneciendo al contexto local.

El origen mantiene una afirmación estrecha sobre la respuesta. El navegador ofrece una transición documentada. La aplicación toma o revisa las decisiones dependientes de consulta cuando conoce la navegación efectiva. «La misma página» deja de ser una promesa que mezcla responsabilidades distintas. La optimización puede adoptarse voluntariamente con un límite comprobable, en lugar de exigir confianza indefinida en todas las capas.

Los beneficios de privacidad también requieren medida. El borrador explica que una caché privada puede evitar parte del procesamiento de identificadores de seguimiento por el origen. Una caché compartida sigue recibiendo las peticiones que los contienen, y el campo no desactiva el seguimiento del cliente. Reutilización no significa anonimato; activación no significa consentimiento. La promesa útil es más pequeña: preparar pronto una respuesta equivalente y vincular la decisión cuando el lector haya hecho una elección real.

Fuentes

  1. Datatracker: estado actual de No-Vary-Search.
  2. Historial de versiones del borrador.
  3. Versión 09 archivada: comparación, caché y seguridad.
  4. Texto de la versión 09.
  5. Fuente estructurada de la versión 09.
  6. Texto de las extensiones de HTTP Working Group.
  7. Debates del repositorio de extensiones HTTP.
  8. Grupo HTTPBIS.
  9. RFC 9110: semántica HTTP.
  10. RFC 9111: almacenamiento en caché HTTP.
  11. RFC 9651: Structured Fields para HTTP.
  12. RFC 6943: comparación de identificadores y seguridad.
  13. Estándar URL de WHATWG.
  14. Estándar Infra de WHATWG.
  15. Chrome: prerenderizado y precauciones al activar con No-Vary-Search.
  16. heng.lu: especificación mínima y decisión futura localizada.
  17. heng.lu: The Policy Mirror.