Imposta Vary sui nomi delle intestazioni della richiesta che il server usa per selezionare la rappresentazione di una pagina pubblica. Su un Mac, prova un’intestazione alla volta, confronta il documento e i metadati restituiti e controlla la risposta predefinita prima di modificare la configurazione.

Questa guida è pensata per chi gestisce un documento pubblico e ne verifica la distribuzione dal Terminale del Mac. L’esempio pratico è una “Guida alle forme” sintetica, disponibile in formato HTML o testo semplice allo stesso URL. L’obiettivo è identificare gli input effettivamente usati per la selezione, configurare la corrispondente intestazione di risposta e verificare il risultato.

Cosa va inserito nell’intestazione Vary di una pagina?

Vary indica i campi della richiesta che possono influire sulla selezione della rappresentazione, oltre al metodo della richiesta e all’URL di destinazione. I suoi valori sono nomi di intestazioni, come Accept, non i tipi di contenuto richiesti. Descrive il comportamento di selezione; aggiungerlo non implementa tale comportamento. RFC 9110: semantica HTTP, sezione 12.5.5.

Ad esempio, se il server seleziona HTML o testo semplice usando Accept, il campo di risposta pertinente è Vary: Accept. Se anche un livello di distribuzione seleziona l’output compresso o non compresso usando Accept-Encoding, mantieni anche questa dimensione: Vary: Accept, Accept-Encoding. Sono esempi condizionali, non una configurazione universale per tutte le pagine. Negoziazione dei contenuti.

La domanda pratica è: una risposta memorizzata nella cache e selezionata per una richiesta potrebbe non essere adatta a un’altra se questa intestazione è cambiata? La memorizzazione nella cache HTTP richiede che i campi indicati corrispondano prima che la risposta venga riutilizzata senza riconvalida. Un campo indicato ma assente corrisponde a un altro campo assente, non a uno presente. RFC 9111: memorizzazione nella cache HTTP, sezione 4.1.

Inizia redigendo un inventario delle regole di selezione. Controlla le regole con cui l’applicazione seleziona i documenti e le eventuali trasformazioni applicate in seguito alla risposta. Un risultato diverso è un indizio utile, ma il fatto che due richieste restituiscano lo stesso risultato non dimostra che un’intestazione sia irrilevante per tutti i valori supportati.

Prepara una matrice di richieste prima di modificare alcunché

Per la Guida alle forme sintetica, supponiamo che il comportamento previsto sia restituire HTML quando è preferito l’HTML, testo semplice quando è preferito il testo semplice e HTML quando Accept è assente. Entrambe le versioni contengono le stesse informazioni neutre: “Cerchio, quadrato, triangolo”. Sono requisiti illustrativi, non osservazioni su un sito pubblicato.

Prova Impostazione della richiesta Risultato previsto Cosa controllare
HTML Accept: text/html Documento HTML Corpo, Content-Type, Vary
Testo semplice Accept: text/plain Documento in testo semplice Corpo, Content-Type, Vary
Predefinito Campo Accept assente Documento HTML Selezione predefinita e Vary
Ripetizione HTML dopo il testo semplice Di nuovo il documento HTML Se la variante precedente influisce sulla distribuzione
Input non usato Modifica un’intestazione assente dalle regole di selezione Stessa rappresentazione selezionata Se occorre esaminare quell’intestazione

Mantieni fissa la compressione durante il primo confronto. Altrimenti, una differenza nei byte potrebbe dipendere dalla compressione anziché da un documento diverso. Esamina prima la selezione del formato, poi la compressione separatamente. La distinzione deriva dai ruoli separati di Accept e Accept-Encoding. Negoziazione dei contenuti.

Registra le differenze significative invece di basarti solo sulle dimensioni dei file. In questo esempio, la risposta in testo semplice dovrebbe contenere i nomi delle forme senza markup HTML e il relativo tipo MIME dovrebbe indicare testo semplice. Se cambia un timestamp generato, occorre indagare prima di considerare ogni differenza di byte come una nuova variante.

Questa matrice è uno strumento diagnostico, non una suite completa di test di negoziazione. Quando i casi di base funzionano, aggiungi le preferenze combinate e i valori di qualità effettivamente supportati dalla pagina. Una semplice richiesta per un singolo tipo non può coprire tutti i rami di un algoritmo di selezione.

Acquisisci risposte confrontabili nel Terminale del Mac

Ti servono un documento di prova pubblico con contenuti sintetici, il suo URL HTTPS definitivo e un Mac con bash e curl disponibili. L’esempio presuppone che il documento di prova supporti già il comportamento HTML/testo semplice descritto sopra. Non crea, carica né pubblica quel documento.

Apri Terminale e incolla il blocco completo qui sotto. Quando richiesto, inserisci l’URL del documento sintetico. Lo script crea una nuova directory temporanea per il rapporto e conserva il corpo di ogni risposta accanto alle intestazioni; non sovrascrive un rapporto precedente.

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

Qui, --header imposta il campo controllato della richiesta, mentre Accept: rimuove il campo Accept generato internamente da curl. --dump-header e --output salvano separatamente intestazioni e corpi. I limiti di tempo per connessione e trasferimento pongono un limite alla durata di ogni richiesta. Queste opzioni sono documentate nel manuale di curl.

Lo script si arresta quando curl segnala un errore di trasferimento o un errore HTTP intercettato da --fail. Prima di riprovare, controlla la directory indicata: le acquisizioni precedenti possono rimanere e un trasferimento non riuscito può lasciare file incompleti. Per scelta, lo script non segue i reindirizzamenti: controlla quindi la riga di stato in ogni file di intestazione. Se hai acquisito un reindirizzamento, usa l’URL finale del documento e avvia un nuovo rapporto. Manuale di curl.

Apri in Finder la directory del rapporto usando il percorso stampato dallo script. Esamina i file con un editor di testo semplice. Confronta html.body con plain.body, poi confronta html.body con html-again.body. Esamina absent.headers con la stessa attenzione riservata alle risposte con preferenze esplicite.

Considera i risultati salvati come osservazioni relative a questa sequenza di richieste. Non dimostrano che una cache condivisa abbia memorizzato alcunché. Se devi verificare il riutilizzo della cache, ripeti la sequenza attraverso il percorso di distribuzione previsto e nelle condizioni documentate in cui la risposta può essere memorizzata nella cache; inverte anche l’ordine, iniziando dal testo semplice.

Applica il risultato nel livello che genera la risposta

Per la Guida alle forme illustrativa, gli indizi sulla selezione del formato dovrebbero confermare che Accept è un campo di selezione. Configuralo nel punto in cui la risposta HTTP viene generata o finalizzata. Se un altro livello aggiunge già un membro Vary necessario, conservalo quando aggiungi il membro relativo alla selezione del formato. L’elenco finale dovrebbe descrivere il comportamento di selezione combinato. RFC 9110: semantica HTTP.

Quello che segue è un frammento di intestazione di risposta per l’esempio, nel caso in cui siano attive sia la selezione del formato sia la negoziazione della compressione. Non è una risposta HTTP completa né un file di configurazione del server.

Vary: Accept, Accept-Encoding

Usa lo stesso elenco Vary previsto per le varianti negoziate e per la risposta predefinita, e conservalo nelle risposte applicabili 304 Not Modified. MDN documenta esplicitamente questo requisito di coerenza. Includi questi percorsi di risposta nella verifica, invece di controllare solo la prima risposta HTML corretta. Intestazione Vary.

Aggiungere un elemento meta con http-equiv="Vary" non è un’alternativa supportata. WHATWG definisce un insieme specifico di direttive pragma HTML, che non include Vary, e spiega che tali direttive sono in gran parte distinte dalle intestazioni HTTP. Configura le vere intestazioni di risposta. Standard HTML: direttive pragma.

Se l’interfaccia di pubblicazione non consente di impostare le intestazioni di risposta, verifica se il livello di hosting o quello dell’applicazione offre un supporto documentato. Se non è disponibile, un’alternativa pratica per questo esempio sintetico consiste nell’assegnare URL distinti ai documenti HTML e di testo semplice, mantenendo stabile la rappresentazione di ciascuno, invece di negoziarne il formato a un unico URL. In questo modo si elimina quella specifica dimensione di selezione; le altre trasformazioni vanno comunque valutate separatamente.

Diagnostica le variazioni mancanti, eccessive e fuorvianti

Usa le acquisizioni per decidere quale verifica eseguire. La guida decisionale seguente si applica al comportamento previsto indicato nell’esempio; non descrive alcun servizio di hosting specifico.

Osservazione Verifica successiva
Le richieste HTML e in testo semplice producono formati diversi, ma Vary omette Accept Esamina il punto in cui viene assemblata l’intestazione di risposta finale
Le varianti esplicite includono Accept, ma la risposta predefinita lo omette Esamina il percorso della risposta di ripiego
La richiesta HTML ripetuta riceve la versione in testo semplice Confronta la selezione all’origine con la distribuzione attraverso la cache
Ogni richiesta produce lo stesso documento HTML Verifica se esiste una negoziazione del formato prima di aggiungere un membro relativo al formato
In Vary compare un’intestazione non correlata Individua la regola di selezione che la richiede prima di rimuoverla
Ridimensionare la finestra del browser cambia l’impaginazione senza modificare l’HTML distribuito Verifica se si tratta di presentazione adattiva anziché di selezione lato server

Il caso in cui manca il valore predefinito merita particolare attenzione: RFC 9111 descrive come l’omissione di Vary dalla risposta predefinita possa far sì che questa venga selezionata per richieste successive, nonostante siano disponibili alternative. Correggi il percorso predefinito insieme alle varianti esplicite. RFC 9111: memorizzazione nella cache HTTP.

Evita di usare Vary: * come scorciatoia per un inventario incompleto. Secondo le regole della memorizzazione nella cache HTTP, una risposta memorizzata contenente quel membro non supera mai il test di corrispondenza. Non indica quali campi della richiesta selezionano il documento. RFC 9111: memorizzazione nella cache HTTP.

Dopo il confronto nel Terminale, è utile anche una verifica nel browser. Lo standard Fetch di WHATWG tiene esplicitamente conto di Vary nella selezione di una risposta dalla cache HTTP. Controlla il documento attraverso il normale percorso di caricamento del browser, oltre che con le richieste curl controllate. Standard Fetch: recupero HTTP dalla rete o dalla cache.

Mantieni coerenti i requisiti di distribuzione delle pagine e quelli di Google Search

Per le pagine che dipendono dal dispositivo, distingui il design responsive dalla distribuzione dinamica. Google descrive il design responsive come la distribuzione dello stesso HTML allo stesso URL su dispositivi diversi, mentre la distribuzione dinamica seleziona HTML diversi usando User-Agent e si basa su Vary: User-Agent. Google consiglia il design responsive perché è più semplice da implementare e mantenere. Best practice per i siti mobile e l’indicizzazione mobile-first.

Di conseguenza, una Guida alle forme sintetica che si limita a riordinare lo stesso HTML con CSS non richiede di variare in base a User-Agent solo per via di tale modifica dell’impaginazione. Se il server seleziona effettivamente HTML diversi in base al dispositivo, aggiungi i casi relativi ai dispositivi alla matrice delle richieste. Google consiglia inoltre di mantenere equivalenti i contenuti principali nelle versioni desktop e mobile. Best practice per i siti mobile e l’indicizzazione mobile-first.

Concludi con un breve registro di distribuzione, facile da esaminare: le regole di selezione del documento, la matrice delle richieste, le risposte acquisite e l’elenco Vary risultante. Ogni intestazione elencata dovrebbe avere un ruolo identificabile, ogni variante supportata dovrebbe restare distinguibile e la risposta predefinita dovrebbe rispettare lo stesso contratto di distribuzione.

Fonti