Nota: alcuni svantaggi della negoziazione del contenuto HTTP sono spiegati in una pagina wiki del WHATWG. HTML5 fornisce alternative alla negoziazione del contenuto tramite, ad esempio, l'elemento <source>.
Uno specifico documento è chiamato risorsa. Quando un client desidera ottenere una risorsa, il client la richiede utilizzando il suo URL. Il server utilizza questo URL per scegliere una delle varianti che fornisce - ogni variante viene chiamata rappresentazione - e restituisce una rappresentazione specifica per il client. La risorsa complessiva, così come ciascuna delle rappresentazioni, ha un URL specifico. Il modo in cui viene scelta una rappresentazione specifica quando la risorsa viene chiamata è determinato dalla negoziazione del contenuto e ci sono diversi modi per negoziare tra il client e il server.
La determinazione della rappresentazione più adatta avviene attraverso uno dei seguenti meccanismi:
Nel corso degli anni sono state avanzate altre proposte di negoziazione dei contenuti, come la negoziazione trasparente dei contenuti e l'intestazione Alternates, ma non hanno ottenuto la giusta attenzione e sono state quindi abbandonate.
Nella negoziazione del contenuto gestita lato server, o negoziazione proattiva del contenuto, il browser (o qualsiasi altro tipo di user-agent) invia diverse intestazioni HTTP insieme all'URL. Queste intestazioni descrivono la scelta preferita dell'utente. Il server li utilizza come suggerimenti e un algoritmo interno sceglie il contenuto migliore da offrire al client. L'algoritmo è specifico del server e non è definito dallo standard. Vedi, ad esempio, l'algoritmo di negoziazione di Apache.
Lo standard HTTP / 1.1 definisce l'elenco delle intestazioni standard che avviano la negoziazione guidata dal server ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Sebbene in senso stretto {{HTTPHeader ("User-Agent")}} non sia in questo elenco, a volte viene anche utilizzato per inviare una rappresentazione specifica della risorsa richiesta, per quanto questa non sia considerata una buona pratica. Il server utilizza l'intestazione {{HTTPHeader ("Vary")}} per indicare quali intestazioni ha effettivamente utilizzato per la negoziazione del contenuto (o più precisamente le intestazioni di risposta associate), in modo che le cache possano funzionare in modo ottimale.
Oltre a questi, c'è una proposta sperimentale per aggiungere più intestazioni all'elenco delle intestazioni disponibili, chiamate suggerimenti del client. I suggerimenti del client indicano il tipo di dispositivo su cui viene eseguito l'user agent (ad esempio, se si tratta di un computer desktop o di un dispositivo mobile).
Anche se la negoziazione del contenuto guidata dal server è il modo più comune per concordare una rappresentazione specifica di una risorsa, presenta diversi svantaggi:
L’ intestazione {{HTTPHeader("Accept")}} elenca i tipi di risorse media MIME che l’interprete vuole processare. È una lista di elementi MIME separati da virgole, ognuno combinato con un indice di qualità, ovvero un parametro che indica il relativo grado di preferenza tra diversi tipi MIME.
L’ intestazione {{HTTPHeader("Accept")}} è definita dal browser, o da qualunque altro interprete, e può variare in base al contesto, come ottenre una pagina HTML, un'immagine, un video o uno script: diverge quando si ottiene un documento inserito nella barra degli indirizzi, o un elemento linkato via {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }}. I browser sono liberi di usare il valore dell’intestazione che pensano sia il più adeguato; è disponibile una lista di valori standard per I browers più comuni. is available.
Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 46 in poi. Il valore Device-Memoryè presente da Chrome 61 in poi.
L’header sperimentale {{HTTPHeader("Accept-CH")}}elenca dati di configurazione che possono essere usati dal server per elaborare una risposta appropriate. I valori validi sono:
| Valore | Significato |
|---|---|
Device-Memory |
Indica in modo approssimativo la quantità di memoria RAM. Questo valore è un approssimazione ottenuta arrotondando alla potenza di due più vicina e dividendo ciò per 1024. Per esempio, 512 megabytes diventano 0.5. |
DPR |
Indica la risoluzione del dispositivo del client. |
Viewport-Width |
Indica la larghezza dell’area visibile in pixel CSS. |
Width |
Indica la reale larghezza di una risorsa (per esempio la larghezza di un’immagine). |
L’ intestazione {{HTTPHeader("Accept-Charset")}} indica al server che tipo di codifica dei caratteri viene accettata dall’interprete. DI solito, è impostata con valori differenti per ogni browser locale, per esempio ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a per l’Europa occidentale.
Essendo UTF-8 molto diffuso e il metodo più usato per la codifica dei caratteri, e per garantire una maggiore privacy attraverso meno configuration-based entropy , il browser omette Accept-Charset l’intestazione: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 e Chrome 27 hanno abbandonato questa intestazione.
Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 61 in poi.
L’intestazione {{HTTPHeader("Accept-CH-Lifetime")}} è usata con il valore Device-Memory dell’intestazione Accept-CH e indica il tempo che il dispositivo dovrebbe impiegare per condividere una certa quantità di memoria del dispositivo con il server. Il valore è in millisecondi ed è opzionale.
L’intestazione {{HTTPHeader("Accept-Encoding")}} definisce il metodo di compressione utilizzato. Il valore è una lista di fattori q (es.: br, gzip;q=0.8) che indica la priorità del valore di codifica. Il valore di default di identità è quello a proprità più bassa (a meno che non sia specificato diversamente).
La comprensione dei messaggi http è uno dei modi migliori per migliorare le prestazioni di un sito web, esso diminuisce la dimensione dei dati trasmessi permettendo un uso migliore della larghezza di banda; I browser inviano sempre questa intestazone e il server deve essere configurato per addatarsi a tale intestazione ed usare la compressione.
L'intestazione Accept-Language L'intestazone {{HTTPHeader("Accept-Language")}} indica il linguaggio predefinito dell'utente. E' una lista di valori con fattori di qualità(es.:"de, en;q=0.7"). Un valore di default è spesso deciso a seconda del linguaggio dell'interfaccia grafica dell'interprete, ma la maggior parte dei browser permette di impostare lingue differenti.
A causa dell'aumento dell'uso dei configuration-based entropy si può usare un valore modificato per identificare l'utente, non è consigliato cambiarlo e un sito web non può fidarsi di questo valore per interpretare la richiesta dell'utente. I Site designers non devono essere troppo scrupolosi nell'usare un interprete attraverso questa intestazione dato che risulterebbe scomodo all'utente:
Accept-Language adottata in base alla lingua dell' utente che spesso non la cambia, perchè non sa come farlo, o perchè non può, come nel caso di un Internet cafè.Anche se esistono usi appropriati di questa intastazione per selezionare contenuto, è considerata una cattiva abitudine affidarsi ad esso per definire quali funzioni sono supportate dall' interprete.
L'intestazione {{HTTPHeader("User-Agent")}} identifica il browser che invia la richiesta. Questa stringa può contenere una lista di product token e commenti separati da spazi.
Un product token è un nome seguito da '/' e un numero di versione, come Firefox/4.0.1. Ci possono essere tanti product token quanti ne vuole l'interprete. Un comment è una stringa qualsiasi delimitata da parentesi. Ovviamente le parentesi non possono essere usate nella stringa. Il formato del commento non è definito da nessuno standard, ma molti browser ci inseriscono molti token, separati da ';'.
In contrasto alle precedenti intestazioni Accept-* che sono inviate dal client, l'intestazione {{HTTPHeader("Vary")}} è inviata dal web server come risposta. Indica la lista delle intestazioni usate dal server durante la fase di negoziazione gestita dal server. L'intestazione è necessaria per informare la cache dei criteri decisionali in modo da replicarli, permettendo alla cache di essere funzionale e prevenendo l'invio di servizi errati all'utente.
Il valore '*' esprime che la fase di negoziazione gestita dal server usa anche informazioni non trasmesse in un'intestazione per scegliere il contenuto appropriato.
L'intestazione Vary è stata aggiunta nella versione HTTP 1.1 ed è necessaria per permettere alle cache di funzionare in modo adeguato. Una cache, per funzionare con la fase di negoziazione gestita dal server necessita di sapere i criteri usati dal server per scegliere il contenuto trasmesso. In questo modo lòa cache può replicare l'argoritmo in modo da fornire contenuti adeguati senza altre richieste al server. Ovviamente il carattere '*' previene la memorizzazione, dato che la cache non conosce che algoritmi ci stanno dietro.
La negoziazione Server-driven presenta alcuni svantaggi: non è molto scalabile. C'è un'intestazione per ogni funzione/caratteristica usate nella negoziazione. Se vuoi usare risoluzione dello schermo deve essere creata una nuova intestazione HTTP. L'invio delle intestazioni deve essere fatto ad ogni richiest. Questo portebrebbe ad una diminuzione delle performance in caso di molte intestazioni. Più intestazioni specifiche vengono inviate, più il complesso risulta ambiguo, portando a problemi di privacy.
Sin dagli albori di HTTP, il protocollo permette un altro tipo di negoziazione: agent-driven negotiation o reactive negotiation. In questa negoziazione, quando si presenta una richiesta ambigua, il server risponde con una pagina contenente dei link alle risorse alternative disponibili. All'utente vengono presentate le risorse e sceglie quale usare.
Sfortunatamente lo standard HTTP non specifica il formato della pagina, permettendo di scegliere tra le risorse disponobili non permettendo una facile automatizzazione del processo. Inoltre si ricade nella negoziazione server-driven, questo metodo è quasi sempre usato insieme allo scripting, specialmente utilizzando JavaScript per i redirect: dopo aver controllato i criteri di memorizzazione, il codice esegue il redirect. Un secondo problema è che è necessaria una richiesta per ottenere la risorsa, compromettendo la disponibilità della risorsa all'utente.