path: root/files/it/web/http/negoziazione-del-contenuto/index.html

---
title: Negoziazione del contenuto
slug: Web/HTTP/negoziazione-del-contenuto
translation_of: Web/HTTP/Content_negotiation
---
<div>Nel protocollo <a href="/it-IT/docs/Glossary/HTTP">HTTP</a>, la <em><strong>negoziazione del contenuto</strong></em> è 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).</div>

<div class="blockIndicator note">
<p class="summary">Nota: alcuni svantaggi della negoziazione del contenuto HTTP sono spiegati <a href="https://wiki.whatwg.org/wiki/Why_not_conneg">in una pagina wiki del WHATWG.</a> HTML5 fornisce alternative alla negoziazione del contenuto tramite, ad esempio, l'elemento <a href="/it-IT/docs/Web/HTML/Element/source">&lt;source&gt;</a>.</p>
</div>

<h2 id="Principi_di_negoziazione_dei_contenuti">Principi di negoziazione dei contenuti</h2>

<p>Uno specifico documento è chiamato <em>risorsa</em>. 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 <em>rappresentazione</em> - 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 <em>negoziazione del contenuto</em> e ci sono diversi modi per negoziare tra il client e il server.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13789/HTTPNego.png" style="height: 311px; width: 767px;"></p>

<p>La determinazione della rappresentazione più adatta avviene attraverso uno dei seguenti meccanismi:</p>

<ul>
 <li>Intestazioni HTTP specifiche da parte del client (<em>negoziazione guidata dal server</em> o <em>negoziazione proattiva</em>), che è il modo standard di negoziare un tipo specifico di risorsa.</li>
 <li>La restituzione dei <a href="/it-IT/docs/Web/HTTP/Status">codici di risposta HTTP</a> {{HTTPStatus("300")}} (Multiple Choices) o {{HTTPStatus("406")}} (Not Acceptable) dal server (<em>negoziazione guidata dall'agente</em> o <em>negoziazione reattiva</em>), utilizzati come meccanismi di riserva.</li>
</ul>

<p>Nel corso degli anni sono state avanzate altre proposte di negoziazione dei contenuti, come la <a href="https://tools.ietf.org/html/rfc2295">negoziazione trasparente dei contenuti</a> e l'intestazione <code>Alternates</code>, ma non hanno ottenuto la giusta attenzione e sono state quindi abbandonate.</p>

<h2 id="Negoziazione_dei_contenuti_gestita_dal_server">Negoziazione dei contenuti gestita dal server</h2>

<p>Nella <em>negoziazione del contenuto gestita lato server</em>, o <em>negoziazione proattiva del contenuto</em>, 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'<a href="http://httpd.apache.org/docs/current/en/content-negotiation.html#algorithm">algoritmo di negoziazione di Apache</a>.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13791/HTTPNegoServer.png" style="height: 380px; width: 767px;"></p>

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

<p>Oltre a questi, c'è una proposta sperimentale per aggiungere più intestazioni all'elenco delle intestazioni disponibili, chiamate <em>suggerimenti del client</em>. 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).</p>

<p>Anche se la negoziazione del contenuto guidata dal server è il modo più comune per concordare una rappresentazione specifica di una risorsa, presenta diversi svantaggi:</p>

<ul>
 <li>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;</li>
 <li>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);</li>
 <li>Poiché vengono inviate diverse rappresentazioni di una determinata risorsa, le cache condivise sono meno efficienti e le implementazioni del server sono più complesse.</li>
</ul>

<h3 id="Intestazione_Accept">Intestazione Accept</h3>

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

<p>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. <a href="/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values"> </a> is available.</p>

<h3 id="L’intestazione_Accept-CH_experimental_inline">L’intestazione Accept-CH {{experimental_inline}}</h3>

<div class="note">
<p>Questa è parte di una tecnologia <strong> sperimentale</strong> chiamata <em>Client Hints</em>. É supportata da Chrome 46 in poi. Il valore Device-Memoryè presente da Chrome 61 in poi.</p>
</div>

<p>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:</p>

<table class="standard-table">
 <thead>
  <tr>
   <th scope="col">Valore</th>
   <th scope="col">Significato</th>
  </tr>
 </thead>
 <tbody>
  <tr>
   <td><code>Device-Memory</code></td>
   <td>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 <code>0.5</code>.</td>
  </tr>
  <tr>
   <td><code>DPR</code></td>
   <td>Indica la risoluzione del dispositivo del client.</td>
  </tr>
  <tr>
   <td><code>Viewport-Width</code></td>
   <td>Indica la larghezza dell’area visibile in pixel CSS.</td>
  </tr>
  <tr>
   <td><code>Width</code></td>
   <td>Indica la reale larghezza di una risorsa (per esempio la larghezza di un’immagine).</td>
  </tr>
 </tbody>
</table>

<h3 id="L’intestazione_Accept-Charset">L’intestazione Accept-Charset</h3>

<p>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 <code>ISO-8859-1,utf-8;q=0.7,*;q=0.7</code> for a per l’Europa occidentale.</p>

<p>Essendo UTF-8 molto diffuso e il metodo più usato per la codifica dei caratteri, <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy"> e per garantire una maggiore privacy attraverso meno</a> <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">configuration-based entropy </a>, il browser omette <code>Accept-Charset</code> l’intestazione: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 e Chrome 27 hanno abbandonato questa intestazione.</p>

<h3 id="L’intestazione_Accept-CH-Lifetime">L’intestazione Accept-CH-Lifetime</h3>

<div class="note">
<p>Questa è parte di una tecnologia <strong> sperimentale</strong> chiamata <em>Client Hints</em>. É supportata da Chrome 61 in poi.</p>
</div>

<p>L’intestazione {{HTTPHeader("Accept-CH-Lifetime")}} è usata con il valore <code>Device-Memory</code> dell’intestazione <code>Accept-CH</code> 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.</p>

<h3 id="L’intestazione_Accept-Encoding">L’intestazione Accept-Encoding</h3>

<p>L’intestazione {{HTTPHeader("Accept-Encoding")}} definisce il metodo di compressione utilizzato. Il valore è una lista di fattori q (es.: <code>br, gzip;q=0.8</code>) che indica la priorità del valore di codifica. Il valore di default di <code>identità</code> è quello a proprità più bassa (a meno che non sia specificato diversamente).</p>

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

<h3 id="L_intestazione_Accept-Language">L' intestazione Accept-Language</h3>

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

<p>A causa dell'aumento dell'uso dei <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">configuration-based entropy</a> 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:</p>

<ul>
 <li>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 <code>Accept-Language</code> 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è.</li>
 <li>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.</li>
</ul>

<h3 id="Lintestazione_User-Agent">L'intestazione User-Agent </h3>

<div class="note">
<p>Anche se esistono usi appropriati di questa intastazione per selezionare contenuto, <a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">è considerata una cattiva abitudine</a> affidarsi ad esso per definire quali funzioni sono supportate dall' interprete.</p>
</div>

<p>L'intestazione {{HTTPHeader("User-Agent")}} identifica il browser che invia la richiesta. Questa stringa può contenere una lista di <em>product token</em> e <em>commenti</em> separati da spazi.</p>

<p>Un <em>product token</em> è un nome seguito da '<code>/</code>' e un numero di versione, come <code>Firefox/4.0.1</code>. Ci possono essere tanti <em>product token</em> quanti ne vuole l'interprete. Un <em>comment </em>è 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 '<code>;</code>'.</p>

<h3 id="Lintestazione_di_risposta_Vary">L'intestazione di risposta Vary </h3>

<p>In contrasto alle precedenti intestazioni <code>Accept-*</code> 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.</p>

<p>Il valore '<code>*</code>' esprime che la fase di negoziazione gestita dal server usa anche informazioni non trasmesse in un'intestazione per scegliere il contenuto appropriato.</p>

<p>L'intestazione <code>Vary</code> è 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 '<code>*</code>' previene la memorizzazione, dato che la cache non conosce che algoritmi ci stanno dietro.</p>

<h2 id="Negoziazione_Agent-driven">Negoziazione Agent-driven</h2>

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

<p>Sin dagli albori di HTTP, il protocollo permette un altro tipo di negoziazione: <em>agent-driven negotiation</em> o <em>reactive negotiation</em>. 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.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13795/HTTPNego3.png"></p>

<p>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 <em>server-driven</em>, 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.</p>