12. Negoziazione del Contenuto (Content Negotiation)

Quando le risposte trasmettono contenuto, sia che indichino un successo o un errore, il server di origine spesso ha modi diversi di rappresentare tali informazioni; ad esempio, in formati, lingue o codifiche diverse. Allo stesso modo, utenti o user agent diversi potrebbero avere capacità, caratteristiche o preferenze diverse che potrebbero influenzare quale rappresentazione, tra quelle disponibili, sarebbe la migliore da consegnare. Per questo motivo, HTTP fornisce meccanismi per la negoziazione del contenuto.

Questa specifica definisce tre modelli di negoziazione del contenuto resi visibili nel protocollo: negoziazione "proattiva", in cui il server seleziona la rappresentazione in base alle preferenze dichiarate dello user agent; negoziazione "reattiva", in cui il server fornisce un elenco di rappresentazioni tra cui lo user agent può scegliere; e negoziazione del "contenuto della richiesta", in cui lo user agent seleziona la rappresentazione per una richiesta futura in base alle preferenze dichiarate dal server in una risposta passata.

Altri modelli di negoziazione del contenuto includono "contenuto condizionale", in cui la rappresentazione è composta da più parti che vengono renderizzate selettivamente in base ai parametri dello user agent; "contenuto attivo", in cui la rappresentazione contiene uno script che effettua richieste aggiuntive (più specifiche) in base alle caratteristiche dello user agent; e "Negoziazione del Contenuto Trasparente" ([RFC2295]), in cui la selezione del contenuto è eseguita da un intermediario. Questi modelli non si escludono a vicenda e ciascuno presenta compromessi in termini di applicabilità e praticità.

Si noti che, in tutti i casi, HTTP non è consapevole della semantica della risorsa. La coerenza con cui un server di origine risponde alle richieste, nel tempo e per client diversi, e quindi la "somiglianza" delle rappresentazioni osservate di una risorsa nel tempo, è determinata interamente dall'entità o dall'algoritmo che seleziona o genera tali risposte.

12.1. Negoziazione Proattiva (Proactive Negotiation)

Quando le preferenze di negoziazione del contenuto vengono inviate dallo user agent in una richiesta per incoraggiare un algoritmo situato sul server a selezionare la rappresentazione preferita, si parla di "negoziazione proattiva" (nota anche come "negoziazione guidata dal server"). La selezione si basa sulle rappresentazioni disponibili della risposta (le dimensioni su cui potrebbe variare, come lingua, codifica del contenuto, ecc.) confrontate con varie informazioni fornite nella richiesta, inclusi sia i campi di negoziazione espliciti di seguito sia le caratteristiche implicite, come l'indirizzo di rete del client o parti del campo User-Agent.

La negoziazione proattiva è vantaggiosa quando l'algoritmo per selezionare tra le rappresentazioni disponibili è difficile da descrivere a uno user agent, o quando il server desidera inviare la sua "migliore ipotesi" allo user agent insieme alla prima risposta (sperando di evitare il ritardo del round-trip di una richiesta successiva se quella "migliore ipotesi" è sufficientemente buona per l'utente). Per migliorare l'ipotesi del server, uno user agent PUÒ (MAY) inviare campi di intestazione della richiesta che descrivono le sue preferenze.

La negoziazione proattiva presenta seri svantaggi:

• È impossibile per il server determinare con precisione cosa potrebbe essere "migliore" per un dato utente, poiché ciò richiederebbe una conoscenza completa sia delle capacità dello user agent sia dell'uso previsto della risposta (ad esempio, l'utente vuole visualizzarla sullo schermo o stamparla su carta?);

• Far descrivere allo user agent le sue capacità in ogni richiesta può essere sia molto inefficiente (dato che solo una piccola percentuale di risposte ha più rappresentazioni) sia un potenziale rischio per la privacy dell'utente;

• Complica l'implementazione di un server di origine e gli algoritmi per generare risposte a una richiesta; e,

• Limita la riutilizzabilità delle risposte per la cache condivisa.

Uno user agent non può fare affidamento sul fatto che le preferenze di negoziazione proattiva vengano costantemente rispettate, poiché il server di origine potrebbe non aver implementato la negoziazione proattiva per la risorsa richiesta o potrebbe decidere che inviare una risposta che non si conforma alle preferenze dello user agent sia meglio che inviare una risposta 406 (Not Acceptable).

Un campo di intestazione Vary (Sezione 12.5.5) viene spesso inviato nelle risposte soggette a negoziazione proattiva per indicare quali parti delle informazioni della richiesta sono state utilizzate nell'algoritmo di selezione.

I campi di intestazione della richiesta Accept, Accept-Charset, Accept-Encoding e Accept-Language sono definiti di seguito affinché uno user agent possa impegnarsi nella negoziazione proattiva del contenuto della risposta. Le preferenze inviate in questi campi si applicano a qualsiasi contenuto nella risposta, incluse le rappresentazioni della risorsa target, le rappresentazioni di errore o stato di elaborazione e potenzialmente anche le varie stringhe di testo che potrebbero apparire nel protocollo.

12.2. Negoziazione Reattiva (Reactive Negotiation)

Con la "negoziazione reattiva" (nota anche come "negoziazione guidata dall'agente"), la selezione del contenuto (indipendentemente dal codice di stato) viene eseguita dallo user agent dopo aver ricevuto una risposta iniziale. Il meccanismo per la negoziazione reattiva può essere semplice come un elenco di riferimenti a rappresentazioni alternative.

Se lo user agent non è soddisfatto del contenuto della risposta iniziale, può eseguire una richiesta GET su una o più delle risorse alternative per ottenere una rappresentazione diversa. La selezione di tali alternative può essere eseguita automaticamente (dallo user agent) o manualmente (ad esempio, dall'utente che seleziona da un menu ipertestuale).

Un server potrebbe scegliere di non inviare una rappresentazione iniziale, se non l'elenco delle alternative, e quindi indicare che la negoziazione reattiva da parte dello user agent è preferita. Ad esempio, le alternative elencate nelle risposte con i codici di stato 300 (Multiple Choices) e 406 (Not Acceptable) includono informazioni sulle rappresentazioni disponibili in modo che l'utente o lo user agent possa reagire effettuando una selezione.

La negoziazione reattiva è vantaggiosa quando la risposta varierebbe su dimensioni comunemente utilizzate (come tipo, lingua o codifica), quando il server di origine non è in grado di determinare le capacità di uno user agent esaminando la richiesta, e generalmente quando vengono utilizzate cache pubbliche per distribuire il carico del server e ridurre l'uso della rete.

La negoziazione reattiva soffre degli svantaggi di trasmettere un elenco di alternative allo user agent, che degrada la latenza percepita dall'utente se trasmessa nella sezione di intestazione, e necessita di una seconda richiesta per ottenere una rappresentazione alternativa. Inoltre, questa specifica non definisce un meccanismo per supportare la selezione automatica, sebbene non impedisca lo sviluppo di tale meccanismo.

12.3. Negoziazione del Contenuto della Richiesta (Request Content Negotiation)

Quando le preferenze di negoziazione del contenuto vengono inviate da un server in una risposta, le preferenze elencate sono chiamate "negoziazione del contenuto della richiesta" perché intendono influenzare la selezione di un contenuto appropriato per richieste successive a quella risorsa. Ad esempio, i campi di intestazione Accept (Sezione 12.5.1) e Accept-Encoding (Sezione 12.5.3) possono essere inviati in una risposta per indicare i tipi di media e le codifiche di contenuto preferiti per richieste successive a quella risorsa.

Analogamente, la Sezione 3.1 di [RFC5789] definisce il campo di intestazione di risposta "Accept-Patch", che consente di scoprire quali tipi di contenuto sono accettati nelle richieste PATCH.

12.4. Caratteristiche dei Campi di Negoziazione del Contenuto (Content Negotiation Field Features)

12.4.1. Assenza (Absence)

Per ciascuno dei campi di negoziazione del contenuto, una richiesta che non include quel campo implica che il mittente non ha preferenze su quella dimensione di negoziazione.

Se un campo di intestazione di negoziazione del contenuto è presente in una richiesta e nessuna delle rappresentazioni disponibili per la risposta può essere considerata accettabile secondo esso, il server di origine può onorare il campo di intestazione inviando una risposta 406 (Not Acceptable) o ignorare il campo di intestazione trattando la risposta come se non fosse soggetta a negoziazione del contenuto per quel campo di intestazione della richiesta. Tuttavia, ciò non implica che il client sarà in grado di utilizzare la rappresentazione.

Nota: Uno user agent che invia questi campi di intestazione rende più facile per un server identificare un individuo in virtù delle caratteristiche della richiesta dello user agent (Sezione 17.13).

12.4.2. Valori di Qualità (Quality Values)

I campi di negoziazione del contenuto definiti da questa specifica utilizzano un parametro comune, denominato "q" (insensibile alle maiuscole/minuscole), per assegnare un "peso" relativo alla preferenza per quel tipo associato di contenuto. Questo peso è denominato "valore di qualità" (o "qvalue") perché lo stesso nome di parametro è spesso utilizzato nelle configurazioni del server per assegnare un peso alla qualità relativa delle varie rappresentazioni che possono essere selezionate per una risorsa.

Il peso è normalizzato a un numero reale nell'intervallo da 0 a 1, dove 0,001 è il meno preferito e 1 è il più preferito; un valore di 0 significa "non accettabile". Se nessun parametro "q" è presente, il peso predefinito è 1.

weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
       / ( "1" [ "." 0*3("0") ] )

Un mittente di qvalue NON DEVE (MUST NOT) generare più di tre cifre dopo il punto decimale. La configurazione utente di questi valori dovrebbe essere limitata allo stesso modo.

12.4.3. Valori Jolly (Wildcard Values)

La maggior parte di questi campi di intestazione, dove indicato, definisce un valore jolly (*) per selezionare valori non specificati. Se nessun jolly è presente, i valori non esplicitamente menzionati nel campo sono considerati non accettabili. All'interno di Vary, un valore jolly significa che la varianza è illimitata.

Nota: In pratica, l'uso di jolly nella negoziazione del contenuto ha un valore pratico limitato, perché è raramente utile dire, ad esempio, "Preferisco image/* più o meno di (qualche altro valore specifico)". Inviando Accept: */*;q=0, i client possono richiedere esplicitamente una risposta 406 (Not Acceptable) se un formato più preferito non è disponibile, ma devono comunque essere in grado di gestire una risposta diversa, poiché il server è autorizzato a ignorare la loro preferenza.

12.5. Campi di Negoziazione del Contenuto (Content Negotiation Fields)

12.5.1. Accept

Il campo di intestazione "Accept" può essere utilizzato dagli user agent per specificare le loro preferenze riguardo ai tipi di media della risposta. Ad esempio, il campo di intestazione Accept può essere utilizzato per indicare che la richiesta è specificamente limitata a un piccolo insieme di tipi desiderati, come nel caso di una richiesta per un'immagine inline.

Quando inviato da un server in una risposta, Accept fornisce informazioni su quali tipi di contenuto sono preferiti nel contenuto di una richiesta successiva alla stessa risorsa.

Accept = #( media-range [ weight ] )

media-range    = ( "*/*"
                   / ( type "/" "*" )
                   / ( type "/" subtype )
                 ) parameters

Il carattere asterisco * viene utilizzato per raggruppare i tipi di media in intervalli, con */* che indica tutti i tipi di media e type/* che indica tutti i sottotipi di quel tipo. Il media-range può includere parametri di tipo di media applicabili a quell'intervallo.

Ogni media-range può essere seguito da parametri di tipo di media applicabili opzionali (ad esempio, charset), seguiti da un parametro "q" opzionale per indicare un peso relativo (Sezione 12.4.2).

Le specifiche precedenti consentivano la comparsa di parametri di estensione aggiuntivi dopo il parametro di peso. La sintassi accept-ext (accept-params, accept-ext) è stata rimossa perché aveva una definizione complicata, non veniva utilizzata in pratica ed è più facilmente distribuibile tramite nuovi campi di intestazione. I mittenti che utilizzano i pesi DOVREBBERO (SHOULD) inviare "q" per ultimo (dopo tutti i parametri media-range). I destinatari DOVREBBERO (SHOULD) trattare qualsiasi parametro denominato "q" come un peso, indipendentemente dall'ordine dei parametri.

Nota: L'uso del nome del parametro "q" per controllare la negoziazione del contenuto interferirebbe con qualsiasi parametro di tipo di media con lo stesso nome. Pertanto, le registrazioni dei tipi di media non consentono parametri denominati "q".

Esempio:

Accept: audio/*; q=0.2, audio/basic

viene interpretato come "Preferisco audio/basic, ma inviami qualsiasi tipo audio se è il migliore disponibile dopo una riduzione di qualità dell'80%".

Un esempio più elaborato è:

Accept: text/plain; q=0.5, text/html,
       text/x-dvi; q=0.8, text/x-c

Verbalmente, questo verrebbe interpretato come "text/html e text/x-c sono i tipi di media ugualmente preferiti, ma se non esistono, invia la rappresentazione text/x-dvi, e se anche quella non esiste, invia la rappresentazione text/plain".

Gli intervalli di media possono essere sovrascritti da intervalli di media più specifici o tipi di media specifici. Se più di un intervallo di media si applica a un dato tipo, il riferimento più specifico ha la precedenza. Ad esempio:

Accept: text/*, text/plain, text/plain;format=flowed, */*

hanno la seguente precedenza:

1. text/plain;format=flowed
2. text/plain
3. text/*
4. */*

Il fattore di qualità del tipo di media associato a un dato tipo viene determinato trovando l'intervallo di media con la precedenza più alta che corrisponde al tipo. Ad esempio:

Accept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,
       text/plain;format=fixed;q=0.4, */*;q=0.5

porterebbe all'associazione dei seguenti valori:

Tipo di Media	Valore di Qualità
text/plain;format=flowed	1
text/plain	0.7
text/html	0.3
image/jpeg	0.5
text/plain;format=fixed	0.4
text/html;level=3	0.7

Nota: A uno user agent potrebbe essere fornito un insieme predefinito di valori di qualità per determinati intervalli di media. Tuttavia, a meno che lo user agent non sia un sistema chiuso che non può interagire con altri agenti di rendering, questo insieme predefinito dovrebbe essere configurabile dall'utente.

12.5.2. Accept-Charset

Il campo di intestazione "Accept-Charset" può essere inviato da uno user agent per indicare le sue preferenze per i set di caratteri nel contenuto di risposta testuale. Ad esempio, questo campo consente agli user agent capaci di comprendere set di caratteri più completi o per scopi speciali di segnalare tale capacità a un server di origine capace di rappresentare informazioni in tali set di caratteri.

Accept-Charset = #( ( token / "*" ) [ weight ] )

I nomi dei set di caratteri sono definiti nella Sezione 8.3.2. Uno user agent PUÒ (MAY) associare un valore di qualità a ciascun set di caratteri per indicare la preferenza relativa dell'utente per quel set di caratteri, come definito nella Sezione 12.4.2. Un esempio è:

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Il valore speciale *, se presente nel campo di intestazione Accept-Charset, corrisponde a ogni set di caratteri non menzionato altrove nel campo.

Nota: Accept-Charset è deprecato perché UTF-8 è diventato quasi onnipresente e l'invio di un elenco dettagliato di set di caratteri preferiti dall'utente spreca larghezza di banda, aumenta la latenza e rende il fingerprinting passivo troppo facile (Sezione 17.13). La maggior parte degli user agent generici non invia Accept-Charset a meno che non sia specificamente configurato per farlo.

12.5.3. Accept-Encoding

Il campo di intestazione "Accept-Encoding" può essere utilizzato per indicare preferenze riguardo all'uso delle codifiche di contenuto (Sezione 8.4.1).

Quando inviato da uno user agent in una richiesta, Accept-Encoding indica le codifiche di contenuto accettabili in una risposta.

Quando inviato da un server in una risposta, Accept-Encoding fornisce informazioni su quali codifiche di contenuto sono preferite nel contenuto di una richiesta successiva alla stessa risorsa.

Il token "identity" viene utilizzato come sinonimo di "nessuna codifica" per comunicare quando nessuna codifica è preferita.

Accept-Encoding  = #( codings [ weight ] )
codings          = content-coding / "identity" / "*"

A ciascun valore di codings PUÒ (MAY) essere assegnato un valore di qualità associato (peso) che rappresenta la preferenza per quella codifica, come definito nella Sezione 12.4.2. Il simbolo asterisco * in un campo Accept-Encoding corrisponde a qualsiasi codifica di contenuto disponibile non esplicitamente elencata nel campo.

Esempi:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Un server verifica se una codifica di contenuto per una data rappresentazione è accettabile utilizzando le seguenti regole:

1. Se nessun campo di intestazione Accept-Encoding è nella richiesta, lo user agent considera accettabile qualsiasi codifica di contenuto.

2. Se la rappresentazione non ha codifica di contenuto, è accettabile per impostazione predefinita a meno che il campo di intestazione Accept-Encoding non la escluda esplicitamente, dichiarando identity;q=0 o *;q=0 senza una voce "identity" più specifica.

3. Se la codifica di contenuto della rappresentazione è una delle codifiche di contenuto elencate nel valore del campo Accept-Encoding, è accettabile a meno che non sia accompagnata da un qvalue di 0. (Come definito nella Sezione 12.4.2, un qvalue di 0 significa "non accettabile".)

Una rappresentazione può essere codificata con più codifiche di contenuto. Tuttavia, la maggior parte delle codifiche di contenuto sono modi alternativi per raggiungere lo stesso scopo (ad esempio, compressione dei dati). Quando si seleziona tra più codifiche di contenuto con lo stesso scopo, la codifica di contenuto accettabile con il qvalue non zero più alto è preferita.

Un campo di intestazione Accept-Encoding con un valore di campo vuoto implica che lo user agent non desidera alcuna codifica di contenuto nella risposta. Se un campo di intestazione Accept-Encoding non vuoto è presente in una richiesta e nessuna delle rappresentazioni disponibili per la risposta ha una codifica di contenuto elencata come accettabile, il server di origine DOVREBBE (SHOULD) inviare una risposta senza alcuna codifica di contenuto a meno che la codifica identity non sia indicata come non accettabile.

Quando il campo di intestazione Accept-Encoding è presente in una risposta, indica quali codifiche di contenuto la risorsa era disposta ad accettare nella richiesta associata. Il valore del campo viene valutato allo stesso modo di una richiesta.

Si noti che queste informazioni sono specifiche per la richiesta associata; l'insieme delle codifiche supportate potrebbe essere diverso per altre risorse sullo stesso server e potrebbe cambiare nel tempo o dipendere da altri aspetti della richiesta (come il metodo di richiesta).

Un server che non riesce a soddisfare una richiesta a causa di una codifica di contenuto non supportata dovrebbe rispondere con uno stato 415 (Unsupported Media Type) e includere un campo di intestazione Accept-Encoding in quella risposta, consentendo ai client di distinguere tra problemi relativi alle codifiche di contenuto e ai tipi di media. Per evitare confusione con problemi relativi ai tipi di media, un server che non riesce a soddisfare una richiesta con uno stato 415 per motivi non correlati alla codifica di contenuto NON DEVE (MUST NOT) includere il campo di intestazione Accept-Encoding.

L'uso più comune di Accept-Encoding è nelle risposte con un codice di stato 415 (Unsupported Media Type), in risposta all'uso ottimistico di una codifica di contenuto da parte dei client. Tuttavia, il campo di intestazione può anche essere utilizzato per indicare ai client che le codifiche di contenuto sono supportate, per ottimizzare le interazioni future. Ad esempio, una risorsa potrebbe includerlo in una risposta 2xx (Successful) quando il contenuto della richiesta avrebbe potuto essere codificato, ma il client non ha utilizzato una codifica di contenuto.

12.5.4. Accept-Language

Il campo di intestazione "Accept-Language" può essere utilizzato dagli user agent per indicare l'insieme di lingue naturali preferite nella risposta. I tag di lingua sono definiti nella Sezione 8.5.1.

Accept-Language = #( language-range [ weight ] )
language-range  =
          <language-range, see [RFC4647], Section 2.1>

A ciascun language-range può essere assegnato un valore di qualità associato che rappresenta una stima della preferenza dell'utente per le lingue specificate da quell'intervallo, come definito nella Sezione 12.4.2. Ad esempio:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

significherebbe: "Preferisco il danese, ma accetterò l'inglese britannico e altri tipi di inglese".

Si noti che alcuni destinatari trattano l'ordine in cui i tag di lingua sono elencati come un'indicazione di priorità decrescente, in particolare per i tag a cui sono assegnati valori di qualità uguali (nessun valore è uguale a q=1). Tuttavia, non ci si può fidare di questo comportamento. Per coerenza e per massimizzare l'interoperabilità, molti user agent assegnano a ciascun tag di lingua un valore di qualità univoco elencandoli anche in ordine decrescente di qualità. Una discussione aggiuntiva sugli elenchi di priorità linguistica si trova nella Sezione 2.3 di [RFC4647].

Per la corrispondenza, la Sezione 3 di [RFC4647] definisce diversi schemi di corrispondenza. Le implementazioni possono offrire lo schema di corrispondenza più appropriato per i loro requisiti. Lo schema "Filtro Base" ([RFC4647], Sezione 3.3.1) è identico allo schema di corrispondenza precedentemente definito per HTTP nella Sezione 14.4 di [RFC2616].

L'invio di un campo di intestazione Accept-Language con le preferenze linguistiche complete dell'utente in ogni richiesta potrebbe essere contrario alle aspettative di privacy dell'utente (Sezione 17.13).

Poiché l'intelligibilità dipende fortemente dall'utente individuale, gli user agent devono consentire il controllo utente sulle preferenze linguistiche (tramite la configurazione dello user agent stesso o impostando per impostazione predefinita un'impostazione di sistema controllabile dall'utente). Uno user agent che non fornisce tale controllo NON DEVE (MUST NOT) inviare un campo di intestazione Accept-Language.

Nota: Gli user agent dovrebbero fornire indicazioni agli utenti quando impostano una preferenza, poiché gli utenti raramente hanno familiarità con i dettagli della corrispondenza linguistica come descritto sopra. Ad esempio, gli utenti potrebbero presumere che selezionando "en-gb", riceveranno qualsiasi tipo di documento inglese se l'inglese britannico non è disponibile. Uno user agent potrebbe suggerire, in tal caso, di aggiungere "en" all'elenco per un migliore comportamento di corrispondenza.

12.5.5. Vary

Il campo di intestazione "Vary" in una risposta descrive quali parti di un messaggio di richiesta, oltre al metodo e all'URI target, potrebbero aver influenzato il processo del server di origine per selezionare il contenuto di questa risposta.

Vary = #( "*" / field-name )

Un valore di campo Vary è il membro jolly * o un elenco di token field-name di richiesta, chiamati campi di intestazione di selezione, che potrebbero aver avuto un ruolo nella selezione della rappresentazione per questa risposta. I potenziali campi di intestazione di selezione non sono limitati ai campi definiti da questa specifica.

Un elenco contenente il membro * segnala che altri aspetti della richiesta potrebbero aver avuto un ruolo nella selezione della rappresentazione della risposta, possibilmente inclusi aspetti al di fuori della sintassi del messaggio (ad esempio, l'indirizzo di rete del client). Un destinatario non sarà in grado di determinare se questa risposta è appropriata per una richiesta successiva senza inoltrare la richiesta al server di origine. Un proxy NON DEVE (MUST NOT) generare un * in un valore di campo Vary.

Ad esempio, una risposta che contiene:

Vary: accept-encoding, accept-language

indica che il server di origine potrebbe aver utilizzato i campi di intestazione Accept-Encoding e Accept-Language della richiesta (o la loro assenza) come fattori determinanti nella scelta del contenuto per questa risposta.

Un campo Vary contenente un elenco di nomi di campo ha due scopi:

1. Informare i destinatari della cache che NON DEVONO (MUST NOT) utilizzare questa risposta per soddisfare una richiesta successiva a meno che la richiesta successiva non abbia gli stessi valori per i campi di intestazione elencati della richiesta originale (vedere Sezione 4.1 di [CACHING]) o il riutilizzo della risposta sia stato convalidato dal server di origine. In altre parole, Vary espande la chiave di cache necessaria per abbinare una nuova richiesta alla voce di cache memorizzata.

2. Informare i destinatari user agent che questa risposta è stata soggetta a negoziazione del contenuto (Sezione 12) e che una rappresentazione diversa potrebbe essere inviata in una richiesta successiva se vengono forniti valori aggiuntivi nei campi di intestazione elencati (negoziazione proattiva).

Un server di origine DOVREBBE (SHOULD) generare un campo di intestazione Vary su una risposta cachabile quando desidera che la risposta venga riutilizzata selettivamente per richieste successive a quella risorsa. In genere, questo è il caso quando il contenuto della risposta è stato adattato per adattarsi meglio alle preferenze espresse da quei campi di intestazione di selezione, come quando un server di origine ha selezionato la lingua della risposta in base al campo di intestazione Accept-Language della richiesta.

Vary può essere omesso quando un server di origine considera la varianza nella selezione del contenuto meno significativa dell'impatto di Vary sulle prestazioni della cache, in particolare quando il riutilizzo è già limitato dalle direttive di risposta della cache (vedere Sezione 5.2 di [CACHING]).

Non è necessario inviare il nome del campo Authorization in Vary perché il riutilizzo di quella risposta per un utente diverso è vietato dalla definizione del campo (Sezione 11.6.2). Allo stesso modo, se il contenuto della risposta è stato selezionato o influenzato dalla regione di rete, ma il server di origine desidera che la risposta memorizzata nella cache venga riutilizzata anche se il destinatario si sposta da una regione all'altra, non è necessario che il server di origine indichi tale varianza in Vary.