L'Header Vary

L'header HTTP Vary è ingannevole nel concetto ma profondamente complesso nella pratica. Una singola direttiva Vary mal posizionata può ridurre il tuo rapporto di cache hit dell'80%, degradando silenziosamente le prestazioni in tutta la tua infrastruttura CDN. Capire come usarlo correttamente è essenziale per chiunque sia responsabile delle prestazioni web e dell'ottimizzazione CDN.

Cos'è Esattamente Vary?

Nella cache HTTP, la regola fondamentale è semplice: un URL è uguale a un oggetto memorizzato in cache. Ma il mondo reale è più complicato. Lo stesso URL potrebbe restituire contenuto diverso a seconda di fattori come il tipo di dispositivo client, le preferenze linguistiche, la posizione geografica o il formato di compressione accettato.

L'header Vary risolve questo problema dicendo alle cache che un singolo URL potrebbe servire più variazioni di contenuto. Quando invii un header Vary, stai istruendo le cache a creare voci di cache separate non solo in base all'URL, ma in base alla combinazione dell'URL più gli header HTTP specificati nella direttiva Vary.

Per esempio:

Vary: Accept-Encoding, User-Agent

Questo dice alle cache che lo stesso URL potrebbe restituire contenuto diverso a seconda sia dell'header Accept-Encoding (solitamente indicando se il client supporta la compressione) che dell'header User-Agent (il browser/dispositivo che effettua la richiesta).

Questo è content negotiation in pratica. Il tuo server sta dicendo: "Servio contenuto diverso in base a questi header, quindi metti in cache ogni variazione separatamente."

Il Problema Classico: Compressione della Risposta

L'uso più comune e legittimo di Vary è per la compressione HTTP. Quando un client supporta la compressione gzip o brotli, invia:

Accept-Encoding: gzip, deflate, br

Il tuo server di origine deve decidere: dovrei inviare la risposta compressa o non compressa? La scelta intelligente è solitamente comprimere per browser moderni e lasciare non compressa per client legacy.

Ma ecco il problema della cache: se invii una risposta compressa al Client A e una risposta non compressa al Client B per lo stesso URL, quelle sono due sequenze di byte completamente diverse. Se la tua cache ha archiviato la versione compressa quando il Client A l'ha richiesta, e poi il Client B richiede lo stesso URL ma non supporta la compressione, la cache non può servire la versione compressa, la romperebbe il client.

La soluzione: Vary: Accept-Encoding

Questo dice alle cache di mantenere voci di cache separate per versioni compresse e non compresse dello stesso contenuto, servendo ogni variante in base alle capacità del client.

Impatto sul Rapporto di Cache Hit: L'Attacco Clone

Ora considera uno scenario diverso. Il tuo sito web ha un design reattivo che si adatta ai viewport mobili, tablet e desktop. Potrebbe essere tentante usare:

Vary: User-Agent

Il problema: ci sono circa 20.000 diverse stringhe User-Agent in circolazione. Ogni valore User-Agent unico crea una voce di cache separata. Un singolo URL che dovrebbe avere un rapporto di cache hit del 90% improvvisamente ha un rapporto di cache hit dello 0,005% perché ogni 20.000 client diversi vede un cache miss.

Questo è l'"attacco clone" all'efficienza della cache. Teoricamente stai servendo contenuto diverso per client diversi. Praticamente, stai distruggendo il tuo rapporto di cache hit creando migliaia di varianti che sono effettivamente identiche.

La soluzione: non usare Vary: User-Agent per il design reattivo. Invece, usa una combinazione di rilevamento dispositivo e normalizzazione. Molti CDN, incluso Transparent Edge, forniscono header X-Device o simili che normalizzano User-Agent in un piccolo set di varianti significative (mobile, tablet, desktop).

Casi d'Uso Comuni e Gestione

Accept-Encoding (Compressione)

Caso d'uso legittimo. La maggior parte dei server web e CDN lo impostano automaticamente. L'eccezione è che lo fa male. Vary: Accept-Encoding non è solo accettabile, è essenziale per il comportamento corretto della cache con la compressione.

Origin (CORS)

Quando servite risposte Cross-Origin Resource Sharing, origini diverse potrebbero richiedere header Access-Control diversi. In questo caso:

Vary: Origin

Questo è legittimo, ma pericoloso. Ogni valore Origin header unico crea una voce di cache separata. Se servite una risorsa CORS in 100 domini client diversi, ora avete 100 varianti di cache. Questo è solitamente accettabile perché i valori Origin sono limitati ai domini specifici che effettuano richieste. Ma vale la pena comprendere il costo della cache.

Accept-Language (Lingua)

Per siti web multilingue, potresti servire contenuto diverso in base alla preferenza linguistica:

Vary: Accept-Language

Questo è ragionevole se hai un numero limitato di varianti linguistiche (5-10), ma problematico se supporti molte lingue perché i valori dell'header Accept-Language possono essere molto granulari (en-US, en-GB, pt-BR, ecc.) e i client possono inviare più valori con indicatori di qualità.

Accept

Content negotiation basato sull'accettazione del tipo MIME:

Vary: Accept

Meno comune ora con le API REST, ma ancora rilevante per le API che servono sia JSON che XML. Ancora una volta, il pericolo è creare troppe varianti.

Raccomandazioni di Transparent Edge

Il principio chiave: minimizzare le direttive Vary e normalizzare gli header su cui vari. Ecco l'approccio tecnico:

1. Normalizzazione degli Header

Prima di applicare le regole Vary, normalizza gli header in arrivo a un set gestibile di varianti. Invece di consentire 20.000 stringhe User-Agent, normalizza a 3-5 categorie di dispositivi. Invece di tutte le 50 varianti Accept-Language, normalizza all'elenco delle lingue supportate.

2. Usa l'Header X-Vary-TCDN di Transparent Edge

Il nostro CDN fornisce X-Vary-TCDN esattamente per questo scopo. Invece di variare in base agli header client grezzi, varierai in base al nostro header normalizzato che rappresenta distinzioni significative:

sub vcl_recv {
    set req.http.X-Vary-TCDN = req.http.X-Vary-TCDN + ";" + req.http.X-Device;
    # Solo 3 varianti per URL (mobile, tablet, desktop), non 20.000.
}

Questo codice VCL viene eseguito durante l'elaborazione della richiesta e configura la normalizzazione del dispositivo. Invece di un header Vary che crea migliaia di voci di cache basate su User-Agent, ottieni esattamente 3 varianti di dispositivi, ciascuna con rapporti di cache hit appropriati.

3. Cache Busting per Varianti Intenzionali

Quando hai veramente bisogno di più varianti, usa tecniche di cache-busting come parametri URL piuttosto che header Vary:

https://example.com/page?device=mobile
https://example.com/page?device=desktop

URL diversi = voci di cache diverse. Ciò elimina i problemi di efficienza della cache che Vary crea mentre è completamente trasparente su quale variante viene servita.

L'Impatto sulla Prestazione di un Vary Disattento

Per illustrare il costo dell'uso disattento di Vary: un sito web che serve 10 milioni di richieste al giorno con un singolo header Vary: User-Agent disattento potrebbe subire:

• Il rapporto di cache hit cala dall'85% al 5%
• Il carico del server di origine aumenta di 10x (il 90% meno richieste servite dalla cache)
• La latenza aumenta perché la maggior parte delle richieste richiede il recupero dall'origine
• I costi di larghezza di banda aumentano notevolmente
• L'esperienza dell'utente si degrada notevolmente

Questo non è teorico. È un errore comune che molte organizzazioni scoprono solo dopo che le prestazioni si sono degradate significativamente.

La soluzione è semplice: sii intenzionale con Vary. Usalo solo quando hai genuina variazioni di contenuto, normalizza gli header per minimizzare le varianti e sfrutta gli header di normalizzazione forniti da CDN come X-Vary-TCDN per mantenere alti i rapporti di cache hit mentre servi comunque varianti appropriate ai diversi client.