3. Representations (Rappresentazioni)

Considerando che una risorsa potrebbe essere qualsiasi cosa, e che l'interfaccia uniforme fornita da HTTP è simile a una finestra attraverso la quale si può solo osservare e agire su tale cosa attraverso la comunicazione di messaggi con un attore indipendente dall'altra parte, è necessaria un'astrazione per "rappresentare" ("prendere il posto di") lo stato attuale o desiderato di quella cosa nelle nostre comunicazioni. Questa astrazione è chiamata rappresentazione (representation) [REST].

Ai fini di HTTP, una "rappresentazione" (representation) è un'informazione che intende riflettere uno stato passato, attuale o desiderato di una determinata risorsa, in un formato che può essere facilmente comunicato tramite il protocollo, e che consiste in un insieme di metadati di rappresentazione e un flusso potenzialmente illimitato di dati di rappresentazione.

Un server di origine (origin server) potrebbe essere fornito o essere in grado di generare più rappresentazioni, ciascuna destinata a riflettere lo stato attuale di una risorsa target. In tali casi, un algoritmo viene utilizzato dal server di origine per selezionare una di quelle rappresentazioni come più applicabile a una data richiesta, solitamente basata sulla negoziazione del contenuto (content negotiation). Questa "rappresentazione selezionata" (selected representation) viene utilizzata per fornire i dati e i metadati per valutare le richieste condizionali [RFC7232] e costruire il payload per le risposte 200 (OK) e 304 (Not Modified) a GET [Section 4.3.1].

3.1. Representation Metadata (Metadati di rappresentazione)

I campi di intestazione di rappresentazione (representation header fields) forniscono metadati sulla rappresentazione. Quando un messaggio include un corpo di payload (payload body), i campi di intestazione di rappresentazione descrivono come interpretare i dati di rappresentazione racchiusi nel corpo di payload. In una risposta a una richiesta HEAD, i campi di intestazione di rappresentazione descrivono i dati di rappresentazione che sarebbero stati racchiusi nel corpo di payload se la stessa richiesta fosse stata una GET.

3.1.1. Processing Representation Data (Elaborazione dei dati di rappresentazione)

Lo scopo dei metadati di rappresentazione è consentire ai destinatari di sapere con quale formato hanno a che fare, quale lingua o lingue utilizza la rappresentazione e quali trasformazioni sono state applicate ai dati di rappresentazione da intermediari intervenuti.

3.1.1.1. Media Type (Tipo di media)

HTTP utilizza i tipi di media Internet [RFC2046] nei campi di intestazione Content-Type (Section 3.1.1.5) e Accept (Section 5.3.2) per fornire tipizzazione e negoziazione di tipi di dati aperta ed estensibile. I tipi di media definiscono sia un formato di dati che vari modelli di elaborazione: come elaborare quei dati in accordo con ciascun contesto in cui vengono ricevuti.

media-type = type "/" subtype *( OWS ";" OWS parameter )
type       = token
subtype    = token

Il tipo/sottotipo può essere seguito da parametri nella forma di coppie nome=valore.

parameter      = token "=" ( token / quoted-string )

I token di tipo, sottotipo e nome parametro non sono sensibili alle maiuscole. I valori dei parametri potrebbero essere sensibili o non sensibili alle maiuscole, a seconda della semantica del nome del parametro. La presenza o l'assenza di un parametro potrebbe essere significativa per l'elaborazione di un tipo di media, a seconda della sua definizione nel registro dei tipi di media.

Un valore di parametro che corrisponde alla produzione di token può essere trasmesso sia come token che all'interno di una stringa quotata. I valori quotati e non quotati sono equivalenti. Ad esempio, i seguenti esempi sono tutti equivalenti, ma il primo è preferito per coerenza:

text/html;charset=utf-8
text/html;charset=UTF-8
text/HTML;charset="utf-8"
text/html; charset="utf-8"

I tipi di media Internet dovrebbero essere registrati presso IANA secondo le procedure definite in [BCP13].

3.1.1.2. Charset (Set di caratteri)

HTTP utilizza nomi di set di caratteri per indicare o negoziare lo schema di codifica dei caratteri di una rappresentazione testuale [RFC6365]. Un set di caratteri è identificato da un token non sensibile alle maiuscole.

charset = token

I nomi dei set di caratteri dovrebbero essere registrati nel registro IANA "Character Sets" (http://www.iana.org/assignments/character-sets) secondo le procedure definite in [RFC2978].

3.1.1.3. Canonicalization and Text Defaults (Canonizzazione e valori predefiniti del testo)

I tipi di media Internet sono registrati con una forma canonica per essere interoperabili tra sistemi con formati di codifica nativi diversi. Le rappresentazioni selezionate o trasferite tramite HTTP dovrebbero essere in forma canonica, per molte delle stesse ragioni descritte dalle Multipurpose Internet Mail Extensions (MIME) [RFC2045]. Tuttavia, le caratteristiche prestazionali delle distribuzioni di posta elettronica (cioè, memorizzare e inoltrare messaggi ai peer) sono significativamente diverse da quelle comuni a HTTP e al Web (servizi di informazioni basati su server). Inoltre, i vincoli di MIME per compatibilità con protocolli di trasferimento di posta più vecchi non si applicano a HTTP (vedi Appendice A).

La forma canonica di MIME richiede che i sottotipi di media del tipo "text" utilizzino CRLF come interruzione di riga del testo. HTTP consente il trasferimento di media testuali con semplici CR o LF da soli che rappresentano un'interruzione di riga, quando tali interruzioni di riga sono coerenti per un'intera rappresentazione. Un mittente HTTP può generare (MAY), e un destinatario deve essere in grado di analizzare (MUST), interruzioni di riga nei media testuali che consistono in CRLF, CR nudo o LF nudo. Inoltre, i media testuali in HTTP non sono limitati ai set di caratteri che utilizzano gli ottetti 13 e 10 per CR e LF, rispettivamente. Questa flessibilità riguardante le interruzioni di riga si applica solo al testo all'interno di una rappresentazione a cui è stato assegnato un tipo di media "text"; non si applica ai tipi "multipart" o agli elementi HTTP al di fuori del corpo di payload (ad esempio, campi di intestazione).

Se una rappresentazione è codificata con una codifica di contenuto (content-coding), i dati sottostanti dovrebbero essere in una forma definita sopra prima di essere codificati.

3.1.1.4. Multipart Types (Tipi multipart)

MIME fornisce una serie di tipi "multipart" - incapsulamenti di una o più rappresentazioni all'interno di un singolo corpo di messaggio. Tutti i tipi multipart condividono una sintassi comune, come definito nella Section 5.1.1 di [RFC2046], e includono un parametro di confine come parte del valore del tipo di media. Il corpo del messaggio stesso è un elemento di protocollo; un mittente deve generare (MUST) solo CRLF per rappresentare interruzioni di riga tra parti del corpo.

Il framing dei messaggi HTTP non utilizza il confine multipart come indicatore della lunghezza del corpo del messaggio, sebbene potrebbe essere utilizzato da implementazioni che generano o elaborano il payload. Ad esempio, il tipo "multipart/byteranges" è definito da HTTP per l'uso in alcune risposte 206 (Partial Content) [RFC7233].

3.1.1.5. Content-Type (Tipo di contenuto)

Il campo di intestazione Content-Type indica il tipo di media della rappresentazione associata: sia la rappresentazione racchiusa nel payload del messaggio che la rappresentazione selezionata, come determinato dalla semantica del messaggio. Il tipo di media indicato definisce sia il formato dei dati che il modo in cui quei dati devono essere elaborati da un destinatario, nell'ambito della semantica del messaggio ricevuto, dopo che tutte le codifiche di contenuto indicate da Content-Encoding sono state decodificate.

Content-Type = media-type

I tipi di media sono definiti nella Section 3.1.1.1. Un esempio del campo è:

Content-Type: text/html; charset=ISO-8859-4

Un mittente che genera un messaggio contenente un corpo di payload dovrebbe generare (SHOULD) un campo di intestazione Content-Type in quel messaggio a meno che il tipo di media previsto della rappresentazione racchiusa non sia sconosciuto al mittente. Se un campo di intestazione Content-Type non è presente, il destinatario può (MAY) assumere un tipo di media di "application/octet-stream" ([RFC2046] Section 4.5.1) o esaminare i dati per determinarne il tipo.

In pratica, i proprietari delle risorse non sempre configurano correttamente il loro server di origine per fornire il Content-Type corretto per una data rappresentazione, con il risultato che alcuni client esamineranno il contenuto del payload e sostituiranno il tipo specificato. I client che lo fanno rischiano di trarre conclusioni errate, che potrebbero esporre a ulteriori rischi di sicurezza (ad esempio, "escalation dei privilegi"). Inoltre, è impossibile determinare l'intento del mittente esaminando il formato dei dati: molti formati di dati corrispondono a più tipi di media che differiscono solo nella semantica di elaborazione. Si incoraggiano gli implementatori a fornire un mezzo per disabilitare tale "content sniffing" quando viene utilizzato.

3.1.2. Encoding for Compression or Integrity (Codifica per compressione o integrità)

3.1.2.1. Content Codings (Codifiche di contenuto)

I valori di codifica del contenuto (content coding values) indicano una trasformazione di codifica che è stata o può essere applicata a una rappresentazione. Le codifiche di contenuto sono utilizzate principalmente per consentire a una rappresentazione di essere compressa o altrimenti utilmente trasformata senza perdere l'identità del suo tipo di media sottostante e senza perdita di informazioni. Frequentemente, la rappresentazione viene memorizzata in forma codificata, trasmessa direttamente e decodificata solo dal destinatario.

content-coding   = token

Tutti i valori di codifica del contenuto non sono sensibili alle maiuscole e dovrebbero essere registrati nel "HTTP Content Coding Registry" (Registro delle codifiche di contenuto HTTP), come definito nella Section 8.4. Vengono utilizzati nei campi di intestazione Accept-Encoding (Section 5.3.4) e Content-Encoding (Section 3.1.2.2).

I seguenti valori di codifica del contenuto sono definiti da questa specifica:

• compress (e x-compress): formato dati "compress" UNIX [Welch]. Storico; non raccomandato per l'uso in nuove applicazioni.

• deflate: il formato "zlib" [RFC1950] in combinazione con il meccanismo di compressione "deflate" [RFC1951].

• gzip (e x-gzip): codifica LZ77 con un CRC a 32 bit [RFC1952].

• identity: la codifica "identity" (nessuna trasformazione). Questa codifica viene utilizzata solo nel campo di intestazione Accept-Encoding e non dovrebbe (SHOULD NOT) essere utilizzata nel campo di intestazione Content-Encoding.

3.1.2.2. Content-Encoding (Codifica del contenuto)

Il campo di intestazione Content-Encoding indica quali codifiche di contenuto sono state applicate alla rappresentazione, oltre a quelle inerenti al tipo di media, e quindi quali meccanismi di decodifica devono essere applicati per ottenere i dati nel tipo di media referenziato dal campo di intestazione Content-Type. Content-Encoding viene utilizzato principalmente per consentire la compressione dei dati di una rappresentazione senza perdere l'identità del suo tipo di media sottostante.

Content-Encoding = 1#content-coding

Un esempio del suo utilizzo è:

Content-Encoding: gzip

Se una o più codifiche sono state applicate a una rappresentazione, il mittente che ha applicato le codifiche deve generare (MUST) un campo di intestazione Content-Encoding che elenchi le codifiche di contenuto nell'ordine in cui sono state applicate. Ulteriori informazioni sui parametri di codifica possono essere fornite da altri campi di intestazione non definiti da questa specifica.

A differenza di Transfer-Encoding (Section 3.3 di [RFC7230]), le codifiche elencate in Content-Encoding sono una caratteristica della rappresentazione; la rappresentazione è definita in termini di forma codificata, e tutti gli altri metadati sulla rappresentazione riguardano la forma codificata a meno che non sia diversamente indicato nella definizione dei metadati. Tipicamente, la rappresentazione viene decodificata solo poco prima del rendering o di un uso analogo.

Se il tipo di media include una codifica inerente, come un formato di dati che è sempre compresso, allora quella codifica non verrebbe ripetuta in Content-Encoding anche se risulta essere lo stesso algoritmo di una delle codifiche di contenuto. Tale codifica di contenuto verrebbe elencata solo se, per qualche bizzarra ragione, viene applicata una seconda volta per formare la rappresentazione. Allo stesso modo, un server di origine potrebbe scegliere di pubblicare gli stessi dati come più rappresentazioni che differiscono solo nel fatto che la codifica sia definita come parte di Content-Type o Content-Encoding, poiché alcuni user agent si comporteranno diversamente nella loro gestione di ciascuna risposta (ad esempio, aprire una finestra di dialogo "Salva con nome..." invece della decompressione automatica e del rendering del contenuto).

Un server di origine può (MAY) rispondere con un codice di stato 415 (Unsupported Media Type) se una rappresentazione nel messaggio di richiesta ha una codifica di contenuto che non è accettabile.

3.1.3. Audience Language (Lingua del pubblico)

3.1.3.1. Language Tags (Tag linguistici)

Un tag linguistico (language tag), come definito in [RFC5646], identifica una lingua naturale parlata, scritta o altrimenti veicolata da esseri umani per la comunicazione di informazioni ad altri esseri umani. I linguaggi informatici sono esplicitamente esclusi.

HTTP utilizza tag linguistici nei campi di intestazione Accept-Language e Content-Language. Accept-Language utilizza la più ampia produzione language-range definita nella Section 5.3.5, mentre Content-Language utilizza la produzione language-tag definita di seguito.

language-tag = <Language-Tag, see [RFC5646], Section 2.1>

Un tag linguistico è una sequenza di uno o più sottotag non sensibili alle maiuscole, ciascuno separato da un carattere trattino ("-", %x2D). Nella maggior parte dei casi, un tag linguistico consiste in un sottotag linguistico primario che identifica un'ampia famiglia di lingue correlate (ad esempio, "en" = inglese), seguito opzionalmente da una serie di sottotag che raffinano o restringono l'ambito di quella lingua (ad esempio, "en-CA" = la varietà di inglese come comunicata in Canada). Gli spazi non sono consentiti all'interno di un tag linguistico. I tag di esempio includono:

en, en-US, en-cockney, i-cherokee, x-pig-latin

Vedere [RFC5646] per ulteriori informazioni.

3.1.3.2. Content-Language (Lingua del contenuto)

Il campo di intestazione Content-Language descrive la o le lingue naturali del pubblico previsto per la rappresentazione. Si noti che questo potrebbe non essere equivalente a tutte le lingue utilizzate all'interno della rappresentazione.

Content-Language = 1#language-tag

I tag linguistici sono definiti nella Section 3.1.3.1. Lo scopo principale di Content-Language è consentire a un utente di identificare e differenziare le rappresentazioni in base alla propria lingua preferita dell'utente. Pertanto, se il contenuto è destinato solo a un pubblico che parla danese, il campo appropriato è:

Content-Language: da

Se non viene specificato alcun Content-Language, l'impostazione predefinita è che il contenuto sia destinato a tutti i pubblici linguistici. Questo potrebbe significare che il mittente non lo considera specifico per alcuna lingua naturale, o che il mittente non sa per quale lingua sia destinato.

Più lingue possono (MAY) essere elencate per contenuti destinati a più pubblici. Ad esempio, una resa del "Trattato di Waitangi" (Treaty of Waitangi), presentata simultaneamente nelle versioni originali in māori e inglese, richiederebbe:

Content-Language: mi, en

Tuttavia, il fatto che più lingue siano presenti all'interno di una rappresentazione non significa che sia destinata a più pubblici linguistici. Un esempio sarebbe un manuale di lingua per principianti, come "Una prima lezione di latino" (A First Lesson in Latin), che è chiaramente destinato a essere utilizzato da un pubblico di lingua inglese. In questo caso, il Content-Language dovrebbe correttamente includere solo "en".

Content-Language può (MAY) essere applicato a qualsiasi tipo di media - non è limitato ai documenti testuali.

3.1.4. Identification (Identificazione)

3.1.4.1. Identifying a Representation (Identificazione di una rappresentazione)

Quando una rappresentazione completa o parziale viene trasferita in un payload di messaggio, è spesso desiderabile per il mittente fornire, o per il destinatario determinare, un identificatore per una risorsa corrispondente a quella rappresentazione.

Per un messaggio di richiesta:

• Se la richiesta ha un campo di intestazione Content-Location, allora il mittente afferma che il payload è una rappresentazione della risorsa identificata dal valore del campo Content-Location. Tuttavia, tale affermazione non può essere considerata attendibile a meno che non possa essere verificata con altri mezzi (non definiti da questa specifica). Le informazioni potrebbero comunque essere utili per i collegamenti alla cronologia delle revisioni.

• Altrimenti, il payload non è identificato.

Per un messaggio di risposta, le seguenti regole vengono applicate nell'ordine fino a quando non viene trovata una corrispondenza:

1. Se il metodo di richiesta è GET o HEAD e il codice di stato della risposta è 200 (OK), 204 (No Content), 206 (Partial Content) o 304 (Not Modified), il payload è una rappresentazione della risorsa identificata dall'URI di richiesta effettivo (Section 5.5 di [RFC7230]).

2. Se il metodo di richiesta è GET o HEAD e il codice di stato della risposta è 203 (Non-Authoritative Information), il payload è una rappresentazione potenzialmente modificata o migliorata della risorsa target come fornita da un intermediario.

3. Se la risposta ha un campo di intestazione Content-Location e il suo valore di campo è un riferimento allo stesso URI dell'URI di richiesta effettivo, il payload è una rappresentazione della risorsa identificata dall'URI di richiesta effettivo.

4. Se la risposta ha un campo di intestazione Content-Location e il suo valore di campo è un riferimento a un URI diverso dall'URI di richiesta effettivo, allora il mittente afferma che il payload è una rappresentazione della risorsa identificata dal valore del campo Content-Location. Tuttavia, tale affermazione non può essere considerata attendibile a meno che non possa essere verificata con altri mezzi (non definiti da questa specifica).

5. Altrimenti, il payload non è identificato.

3.1.4.2. Content-Location (Posizione del contenuto)

Il campo di intestazione Content-Location fa riferimento a un URI che può essere utilizzato come identificatore per una risorsa specifica corrispondente alla rappresentazione nel payload di questo messaggio. In altre parole, se si dovesse eseguire una richiesta GET su questo URI al momento della generazione di questo messaggio, allora una risposta 200 (OK) conterrebbe la stessa rappresentazione che è racchiusa come payload in questo messaggio.

Content-Location = absolute-URI / partial-URI

Il valore Content-Location non è una sostituzione dell'URI di richiesta effettivo (Section 5.5 di [RFC7230]). È un metadato di rappresentazione. Ha la stessa sintassi e semantica del campo di intestazione con lo stesso nome definito per le parti del corpo MIME nella Section 4 di [RFC2557]. Tuttavia, la sua presenza in un messaggio HTTP ha alcune implicazioni speciali per i destinatari HTTP.

Se Content-Location è incluso in un messaggio di risposta 2xx (Successful) e il suo valore si riferisce (dopo la conversione in forma assoluta) a un URI che è lo stesso dell'URI di richiesta effettivo, allora il destinatario può (MAY) considerare il payload come una rappresentazione corrente di quella risorsa al momento indicato dalla data di origine del messaggio. Per una richiesta GET (Section 4.3.1) o HEAD (Section 4.3.2), questo è lo stesso della semantica predefinita quando non viene fornito alcun Content-Location dal server. Per una richiesta che cambia lo stato come PUT (Section 4.3.4) o POST (Section 4.3.3), ciò implica che la risposta del server contenga la nuova rappresentazione di quella risorsa, distinguendola così dalle rappresentazioni che potrebbero solo riportare l'azione (ad esempio, "Ha funzionato!"). Ciò consente alle applicazioni di authoring di aggiornare le loro copie locali senza la necessità di una successiva richiesta GET.

Se Content-Location è incluso in un messaggio di risposta 2xx (Successful) e il suo valore di campo si riferisce a un URI che differisce dall'URI di richiesta effettivo, allora il server di origine afferma che l'URI è un identificatore per una risorsa diversa corrispondente alla rappresentazione racchiusa. Tale affermazione può essere considerata attendibile solo se entrambi gli identificatori condividono lo stesso proprietario della risorsa, il che non può essere determinato programmaticamente tramite HTTP.

• Per una risposta a una richiesta GET o HEAD, questo è un'indicazione che l'URI di richiesta effettivo si riferisce a una risorsa soggetta a negoziazione del contenuto e il valore del campo Content-Location è un identificatore più specifico per la rappresentazione selezionata.

• Per una risposta 201 (Created) a una richiesta POST, il valore del campo Content-Location è un riferimento a una risorsa che corrisponde ai dati inviati (cioè, una risorsa distinta da quella identificata dall'URI di richiesta effettivo).

• Altrimenti, tale Content-Location indica che questo payload è una rappresentazione di qualche risorsa diversa dal target del messaggio di richiesta e non ha altro significato per HTTP.

Se Content-Location è incluso in un messaggio di risposta e la rappresentazione consiste in più parti, come indicato da un Content-Type di "multipart/*", allora ogni parte può (MAY) avere il proprio Content-Location per indicare la risorsa corrispondente a quella parte. Altrimenti, Content-Location si applica solo al payload nel suo complesso.

3.2. Representation Data (Dati di rappresentazione)

I dati di rappresentazione associati a un messaggio HTTP vengono forniti come corpo di payload del messaggio o referenziati dalla semantica del messaggio e dall'URI di richiesta effettivo. I dati di rappresentazione sono in un formato e una codifica definiti dai campi di intestazione dei metadati di rappresentazione.

Il tipo di dati dei dati di rappresentazione è determinato tramite i campi di intestazione Content-Type e Content-Encoding. Questi definiscono un modello di codifica ordinato a due livelli:

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Payload Semantics (Semantica del payload)

Alcuni messaggi HTTP trasferiscono una rappresentazione completa o parziale come "payload" del messaggio. In alcuni casi, un payload potrebbe contenere solo i campi di intestazione della rappresentazione associata (ad esempio, risposte a HEAD) o solo alcune parti dei dati di rappresentazione (ad esempio, il codice di stato 206 (Partial Content)).

Lo scopo di un payload in una richiesta è definito dalla semantica del metodo. Ad esempio, una rappresentazione nel payload di una richiesta PUT (Section 4.3.4) rappresenta lo stato desiderato della risorsa target se la richiesta viene applicata con successo, mentre una rappresentazione nel payload di una richiesta POST (Section 4.3.3) rappresenta informazioni da elaborare dalla risorsa target.

In una risposta, lo scopo del payload è definito sia dal metodo di richiesta che dal codice di stato della risposta. Ad esempio, il payload di una risposta 200 (OK) a GET (Section 4.3.1) rappresenta lo stato attuale della risorsa target, come osservato al momento della data di origine del messaggio (Section 7.1.1.2), mentre il payload dello stesso codice di stato in una risposta a POST potrebbe rappresentare sia il risultato dell'elaborazione che il nuovo stato della risorsa target dopo l'applicazione dell'elaborazione.

Un payload è considerato "completo" (complete) nei seguenti casi:

• l'intera sezione di intestazione è stata ricevuta e la lunghezza del corpo di payload indicata è zero;

• un payload chunked è completo quando la parte del corpo chunked è completa (come indicato dal chunk di lunghezza zero e dal CRLF finale);

• una lunghezza di payload sconosciuta è completa quando la connessione viene chiusa.

3.4. Content Negotiation (Negoziazione del contenuto)

Quando le risposte veicolano informazioni di payload, sia che indichino un successo o un errore, il server di origine ha spesso modi diversi di rappresentare quelle 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 meglio consegnare. Per questo motivo, HTTP fornisce meccanismi per la negoziazione del contenuto.

Questa specifica definisce tre modelli di negoziazione del contenuto che possono essere resi visibili all'interno del protocollo: "proattiva" (proactive), dove il server seleziona la rappresentazione in base alle preferenze dichiarate dall'user agent; "reattiva" (reactive), dove il server fornisce un elenco di rappresentazioni tra cui l'user agent può scegliere; e "contenuto della richiesta" (request content), dove l'user agent seleziona la rappresentazione per un payload di richiesta. Altri modelli di negoziazione del contenuto includono "contenuto condizionale" (conditional content), dove la rappresentazione consiste in più parti che vengono rese selettivamente in base ai parametri dell'user agent, "contenuto attivo" (active content), dove la rappresentazione contiene uno script che effettua richieste aggiuntive (più specifiche) in base alle caratteristiche dell'user agent, e "Transparent Content Negotiation" ([RFC2295]), dove la selezione del contenuto viene eseguita da un intermediario. Questi modelli non si escludono a vicenda e ciascuno ha 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 attraverso le dimensioni variabili della negoziazione del contenuto, e quindi la "somiglianza" delle rappresentazioni osservate di una risorsa nel tempo, è determinata interamente da qualsiasi entità o algoritmo che selezioni o generi quelle risposte. HTTP non presta attenzione all'uomo dietro la tenda.

3.4.1. Proactive Negotiation (Negoziazione proattiva)

Quando le preferenze di negoziazione del contenuto vengono inviate dall'user agent in una richiesta per incoraggiare un algoritmo situato sul server a selezionare la rappresentazione preferita, si chiama negoziazione proattiva (proactive negotiation) (nota anche come negoziazione guidata dal server). La selezione si basa sulle rappresentazioni disponibili per una 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 della Section 5.3 che 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 un user agent, o quando il server desidera inviare la sua "migliore ipotesi" all'user agent insieme alla prima risposta (sperando di evitare il ritardo di andata e ritorno di una richiesta successiva se la "migliore ipotesi" è sufficientemente buona per l'utente). Per migliorare l'ipotesi del server, un user agent può (MAY) inviare campi di intestazione di richiesta che descrivono le sue preferenze.

La negoziazione proattiva presenta seri svantaggi:

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

• Far descrivere all'user agent le sue capacità in ogni richiesta può essere sia molto inefficiente (dato che solo una piccola percentuale di risposte ha più rappresentazioni) che 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 memorizzazione nella cache condivisa.

Un user agent non può fare affidamento sul fatto che le preferenze di negoziazione proattiva vengano rispettate in modo coerente, poiché il server di origine potrebbe non implementare la negoziazione proattiva per la risorsa richiesta o potrebbe decidere che l'invio di una risposta che non si conforma alle preferenze dell'user agent è migliore dell'invio di una risposta 406 (Not Acceptable).

Un campo di intestazione Vary (Section 7.1.4) viene spesso inviato in una risposta soggetta a negoziazione proattiva per indicare quali parti delle informazioni di richiesta sono state utilizzate nell'algoritmo di selezione.

3.4.2. Reactive Negotiation (Negoziazione reattiva)

Con la negoziazione reattiva (reactive negotiation) (nota anche come negoziazione guidata dall'agente), la selezione della migliore rappresentazione della risposta (indipendentemente dal codice di stato) viene eseguita dall'user agent dopo aver ricevuto una risposta iniziale dal server di origine che contiene un elenco di risorse per rappresentazioni alternative. Se l'user agent non è soddisfatto della rappresentazione della risposta iniziale, può eseguire una richiesta GET su una o più delle risorse alternative, selezionate in base ai metadati inclusi nell'elenco, per ottenere una forma diversa di rappresentazione per quella risposta. La selezione delle alternative può essere eseguita automaticamente dall'user agent o manualmente dall'utente selezionando da un menu generato (possibilmente ipertestuale).

Si noti che quanto sopra si riferisce alle rappresentazioni della risposta, in generale, non alle rappresentazioni della risorsa. Le rappresentazioni alternative non sono necessariamente rappresentazioni della stessa risorsa, sebbene potrebbero esserlo.

Un server potrebbe scegliere di non inviare una rappresentazione iniziale, diversa dall'elenco di alternative, e quindi indicare che è preferita la negoziazione reattiva da parte dell'user agent. 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 l'user agent possano 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 un user agent esaminando la richiesta, e generalmente quando vengono utilizzate cache pubbliche per distribuire il carico del server e ridurre l'utilizzo della rete.

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

3.4.3. Request Content Negotiation (Negoziazione del contenuto della richiesta)

Quando le preferenze di negoziazione del contenuto vengono inviate nella risposta di un server a un client, il client può utilizzare tali preferenze per determinare quale rappresentazione sia migliore per le richieste successive a quella risorsa. Questo è chiamato negoziazione del contenuto della richiesta (request content negotiation) (nota anche come "negoziazione del contenuto come qualità del servizio").

Ad esempio, un campo di intestazione Accept in una risposta 415 (Unsupported Media Type) potrebbe indicare quali tipi di media sono accettati in una richiesta PUT a quella risorsa, o il campo Accept-Language di una risposta potrebbe indicare le preferenze linguistiche del servizio.

---