Configura Vary con los nombres de los encabezados de solicitud que tu servidor usa para seleccionar la representación de una página pública. En un Mac, prueba un encabezado a la vez, compara el documento y los metadatos devueltos, y comprueba la respuesta predeterminada antes de cambiar la configuración.

Esta guía está pensada para quien mantiene un documento público y comprueba cómo se entrega desde la Terminal de Mac. El ejemplo práctico es una «Guía de formas» sintética disponible en HTML o texto sin formato en una misma URL. La tarea consiste en identificar los datos de entrada que realmente determinan la selección, configurar el encabezado de respuesta correspondiente y verificar el resultado.

¿Qué debe incluir el encabezado Vary de una página?

Vary indica los campos de solicitud que podrían influir en la selección de la representación, además del método de solicitud y la URL de destino. Sus valores son nombres de encabezados, como Accept, no los tipos de medios solicitados. Describe el comportamiento de selección; añadirlo no implementa ese comportamiento. RFC 9110: Semántica de HTTP, sección 12.5.5.

Por ejemplo, si el servidor selecciona HTML o texto sin formato usando Accept, el campo de respuesta pertinente es Vary: Accept. Si una capa de entrega también selecciona una salida comprimida o sin comprimir usando Accept-Encoding, conserva también esa dimensión: Vary: Accept, Accept-Encoding. Son ejemplos condicionales, no una configuración universal para todas las páginas. Negociación de contenido.

La pregunta práctica es: ¿podría una respuesta almacenada en caché y seleccionada para una solicitud no ser adecuada para otra porque cambió este encabezado? Para reutilizar una respuesta sin revalidarla, el almacenamiento en caché HTTP exige que coincidan los campos indicados. Si un campo indicado no está presente, coincide con otro campo también ausente, no con uno presente. RFC 9111: Almacenamiento en caché HTTP, sección 4.1.

Empieza por elaborar un inventario de selección. Comprueba las reglas de selección de documentos de la aplicación y cualquier transformación de respuesta que se aplique después. Un resultado distinto aporta información útil, pero que dos solicitudes devuelvan el mismo resultado no demuestra que un encabezado sea irrelevante para todos los valores admitidos.

Prepara una matriz de solicitudes antes de editar nada

Para la Guía de formas sintética, supongamos que el comportamiento previsto es devolver HTML ante una preferencia por HTML, texto sin formato ante una preferencia por texto sin formato y HTML cuando Accept está ausente. Ambas versiones contienen la misma información neutra: «Círculo, cuadrado, triángulo». Estos son requisitos ilustrativos, no observaciones de un sitio publicado.

Prueba Configuración de la solicitud Resultado previsto Qué inspeccionar
HTML Accept: text/html Documento HTML Cuerpo, Content-Type, Vary
Texto sin formato Accept: text/plain Documento de texto sin formato Cuerpo, Content-Type, Vary
Predeterminada Sin campo Accept Documento HTML Selección predeterminada y Vary
Repetición Solicitar HTML después del texto sin formato De nuevo, documento HTML Si la variante anterior afecta a la entrega
Entrada no usada Cambiar un encabezado que no figura en las reglas de selección La misma representación seleccionada Si hace falta investigar ese encabezado

Mantén fija la compresión durante la primera comparación. De lo contrario, una diferencia en los bytes podría deberse a la compresión y no a un documento distinto. Investiga primero la selección del formato y luego la compresión por separado. Esta distinción corresponde a las funciones distintas de Accept y Accept-Encoding. Negociación de contenido.

Registra las diferencias relevantes en lugar de basarte solo en el tamaño del archivo. En este ejemplo, la respuesta de texto sin formato debe contener los nombres de las formas sin marcado HTML, y su tipo de medio debe describir el texto sin formato. Si cambia una marca de tiempo generada, investígala antes de considerar cada diferencia de bytes como una nueva variante.

Esta matriz es una ayuda de diagnóstico, no un conjunto completo de pruebas de negociación. Cuando funcionen los casos básicos, añade las preferencias combinadas y los valores de calidad que realmente admite la página. Una solicitud con un solo tipo no permite probar todas las ramas de un algoritmo de selección.

Captura respuestas comparables en la Terminal de Mac

Necesitas un documento de prueba público que contenga material sintético, su URL HTTPS definitiva y un Mac con bash y curl disponibles. El ejemplo supone que el documento de prueba ya admite el comportamiento HTML/texto sin formato descrito antes. No crea, carga ni publica ese documento.

Abre Terminal y pega el bloque completo de abajo. Cuando se te solicite, introduce la URL de tu documento sintético. El script crea un directorio nuevo para el informe temporal y guarda el cuerpo de cada respuesta junto a sus encabezados; no sobrescribe un informe anterior.

bash <<'BASH'
set -eu

printf 'Public synthetic page URL: ' > /dev/tty
IFS= read -r page_url < /dev/tty

case "$page_url" in
  https://*) ;;
  *) printf 'Enter an HTTPS URL.\n' >&2; exit 1 ;;
esac

report_dir=$(mktemp -d "${TMPDIR:-/tmp}/vary-check.XXXXXX")
printf 'Report directory: %s\n' "$report_dir"

for sample in html plain absent html-again; do
  case "$sample" in
    html|html-again) accept_header='Accept: text/html' ;;
    plain) accept_header='Accept: text/plain' ;;
    absent) accept_header='Accept:' ;;
  esac

  curl --disable --silent --show-error --fail \
    --connect-timeout 5 --max-time 20 \
    --header "$accept_header" \
    --header 'Accept-Encoding: identity' \
    --dump-header "$report_dir/$sample.headers" \
    --output "$report_dir/$sample.body" \
    --url "$page_url"
done

printf 'Finished. Responses saved in: %s\n' "$report_dir"
BASH

Aquí, --header proporciona el campo de solicitud controlado y Accept: elimina el campo Accept que curl genera internamente. --dump-header y --output guardan por separado los encabezados y los cuerpos. Los límites de tiempo de conexión y transferencia acotan cada solicitud. Estas opciones están documentadas en el manual de curl.

El script se detiene cuando curl informa de un error de transferencia o de un error HTTP incluido en --fail. Inspecciona el directorio indicado antes de volver a intentarlo: pueden quedar capturas anteriores y una transferencia fallida puede dejar archivos incompletos. El script no sigue las redirecciones, así que comprueba la línea de estado en cada archivo de encabezados. Si capturaste una redirección, usa la URL final del documento e inicia un informe nuevo. Manual de curl.

Abre el directorio del informe en Finder usando la ruta que imprime el script. Inspecciona los archivos con un editor de texto sin formato. Compara html.body con plain.body y luego compara html.body con html-again.body. Inspecciona absent.headers con el mismo cuidado que las respuestas con preferencias explícitas.

Considera los resultados guardados como observaciones de esta secuencia de solicitudes. No demuestran que una caché compartida haya almacenado nada. Si necesitas probar la reutilización de la caché, repite la secuencia a través de la ruta de entrega prevista, bajo las condiciones documentadas para que se pueda almacenar en caché, y también invierte el orden para que el texto sin formato vaya primero.

Aplica el resultado en la capa que genera la respuesta

En la Guía de formas ilustrativa, la evidencia de selección de formato debería confirmar que Accept es un campo de selección. Configúralo donde se genere o finalice la respuesta HTTP. Si otra capa ya aporta un miembro necesario de Vary, consérvalo al añadir el miembro de selección de formato. La lista final debe describir el comportamiento combinado de selección. RFC 9110: Semántica de HTTP.

Lo siguiente es un fragmento de encabezados de respuesta para el ejemplo cuando están activas tanto la selección de formato como la negociación de compresión. No es una respuesta HTTP completa ni un archivo de configuración del servidor.

Vary: Accept, Accept-Encoding

Usa la misma lista prevista de Vary en las variantes negociadas y en la respuesta predeterminada, y consérvala en las respuestas 304 Not Modified correspondientes. MDN documenta explícitamente este requisito de coherencia. Incluye estas rutas de respuesta en la verificación, en vez de comprobar únicamente la primera respuesta HTML correcta. Encabezado Vary.

Añadir un elemento meta con http-equiv="Vary" no es una alternativa admitida. WHATWG define un conjunto específico de directivas pragma de HTML, que no incluye Vary, y explica que esas directivas son en gran medida independientes de los encabezados HTTP. Configura los encabezados de respuesta reales. Estándar HTML: Directivas pragma.

Si tu interfaz de publicación no permite configurar encabezados de respuesta, comprueba si la capa de alojamiento o de aplicación ofrece compatibilidad documentada. Si no está disponible, una alternativa práctica para este ejemplo sintético es dar URL distintas y representaciones estables a los documentos HTML y de texto sin formato, en lugar de negociar sus formatos en una misma URL. Así se elimina esa dimensión concreta de selección; cualquier otra transformación debe evaluarse por separado.

Diagnostica la variación ausente, excesiva o engañosa

Usa las capturas para decidir qué investigar a continuación. La siguiente guía de decisión se aplica al comportamiento indicado en el ejemplo; no afirma nada sobre ningún servicio de alojamiento en particular.

Observación Siguiente investigación
Las solicitudes de HTML y de texto sin formato producen formatos distintos, pero Vary no incluye Accept Inspecciona dónde se compone el encabezado de respuesta final
Las variantes explícitas incluyen Accept, pero la respuesta predeterminada lo omite Inspecciona la ruta de respuesta alternativa
La solicitud repetida de HTML recibe la versión de texto sin formato Compara la selección en el origen con la entrega a través de la caché
Todas las solicitudes producen el mismo documento HTML Comprueba si existe negociación de formato antes de añadir un miembro relacionado con el formato
Aparece en Vary un encabezado sin relación con la selección Encuentra la regla de selección que lo exige antes de eliminarlo
Cambiar el tamaño de la ventana del navegador modifica el diseño sin cambiar el HTML entregado Comprueba si se trata de una presentación adaptable y no de una selección del servidor

El caso en que falta el encabezado en la respuesta predeterminada merece especial atención: RFC 9111 describe cómo omitir Vary en una respuesta predeterminada puede hacer que se seleccione esa respuesta para solicitudes posteriores pese a que haya alternativas disponibles. Corrige la ruta predeterminada junto con las variantes explícitas. RFC 9111: Almacenamiento en caché HTTP.

Evita usar Vary: * como atajo para un inventario sin terminar. Según las reglas de almacenamiento en caché HTTP, una respuesta almacenada que contenga ese miembro siempre falla la prueba de coincidencia. No identifica qué campos de solicitud determinan la selección del documento. RFC 9111: Almacenamiento en caché HTTP.

Una comprobación en el navegador sigue siendo útil después de la comparación en la Terminal. El estándar Fetch de WHATWG tiene en cuenta explícitamente Vary al seleccionar una respuesta de la caché HTTP. Comprueba el documento mediante su ruta normal de carga en el navegador y también con solicitudes curl controladas. Estándar Fetch: obtención desde la red HTTP o la caché.

Alinea la entrega de la página con los requisitos de Google Search

En páginas cuyo contenido depende del dispositivo, distingue entre diseño adaptable y entrega dinámica. Google documenta que el diseño adaptable ofrece el mismo HTML en la misma URL en todos los dispositivos, mientras que la entrega dinámica selecciona HTML distinto mediante User-Agent y depende de Vary: User-Agent. Google recomienda el diseño adaptable por su facilidad de implementación y mantenimiento. Mejores prácticas para sitios móviles e indexación centrada en móviles.

Por consiguiente, una Guía de formas sintética que solo reorganiza el mismo HTML con CSS no obtiene motivo alguno para variar según User-Agent por ese cambio de diseño únicamente. Si el servidor realmente selecciona HTML distinto según el dispositivo, añade esos casos de dispositivo a la matriz de solicitudes. Google también recomienda mantener equivalente el contenido principal entre las versiones de escritorio y móvil. Mejores prácticas para sitios móviles e indexación centrada en móviles.

Termina con un registro de entrega breve y fácil de revisar: las reglas de selección de documentos, la matriz de solicitudes, las respuestas capturadas y la lista resultante de Vary. Cada encabezado incluido debe cumplir una función identificable, cada variante admitida debe seguir siendo distinguible y la respuesta predeterminada debe seguir el mismo contrato de entrega.

Fuentes