Negoziazione del contenuto

Nel protocollo HTTP, la negoziazione del contenuto è il meccanismo utilizzato per servire diverse rappresentazioni di una risorsa avente medesimo URI, in modo che il programma utente possa specificare quale sia più adatta all'utente (ad esempio, quale lingua di un documento, quale formato immagine o quale codifica del contenuto).

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>.

Principi di negoziazione dei contenuti

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:

  • Intestazioni HTTP specifiche da parte del client (negoziazione guidata dal server o negoziazione proattiva), che è il modo standard di negoziare un tipo specifico di risorsa.
  • La restituzione dei codici di risposta HTTP 300 (Multiple Choices) o 406 (Not Acceptable) dal server (negoziazione guidata dall'agente o negoziazione reattiva), utilizzati come meccanismi di riserva.

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.

Negoziazione dei contenuti gestita dal server

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 (Accept, Accept-Charset, Accept-Encoding, Accept-Language). Sebbene in senso stretto 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 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:

  • Il server non ha una conoscenza totale del browser. Anche con l'estensione dei suggerimenti del client, non ha una conoscenza completa delle capacità del browser. A differenza della negoziazione del contenuto reattivo in cui il client fa la scelta, la scelta del server è sempre piuttosto arbitraria;
  • Le informazioni fornite dal client sono piuttosto dettagliate (la compressione dell'intestazione HTTP / 2 mitiga questo problema) e un rischio per la privacy (impronta digitale HTTP);
  • Poiché vengono inviate diverse rappresentazioni di una determinata risorsa, le cache condivise sono meno efficienti e le implementazioni del server sono più complesse.

Intestazione Accept

L’ intestazione 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 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 <img>, <video> or <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.

L’intestazione Accept-CH This is an experimental API that should not be used in production code.

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 Accept-CHelenca 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 Accept-Charset

L’ intestazione 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.

L’intestazione Accept-CH-Lifetime

Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 61 in poi.

L’intestazione 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 Accept-Encoding

L’intestazione 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'intestazione Accept-Language L'intestazone 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:

  • Devono sempre fornire un modo per ovviare al linguaggio scelto dal server, ad esempio fornendo una scelta di lingue nel sito. La maggiorparte degli interpreti fornisce un valore di default dell'intestazione 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è.
  • Una volta che l'utente ha cambiato la lingua scelta dal server il sito non deve più identificare la lingua e deve usare la lingua esplicitamente scelta. In altre parole, solo la pagina iniziale del sito deve identificare la lingua adatta usando questa intestazione.

L'intestazione User-Agent 

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 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 ';'.

L'intestazione di risposta Vary 

In contrasto alle precedenti intestazioni Accept-* che sono inviate dal client, l'intestazione  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.

Negoziazione Agent-driven

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 negotiationreactive 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.