5. Request Header Fields (Campi di intestazione della richiesta)

Un client invia campi di intestazione della richiesta per fornire ulteriori informazioni sul contesto della richiesta, rendere la richiesta condizionale in base allo stato della risorsa target, suggerire formati preferiti per la risposta, fornire credenziali di autenticazione o modificare l'elaborazione prevista della richiesta. Questi campi agiscono come modificatori della richiesta, simili ai parametri di un'invocazione di metodo in un linguaggio di programmazione.

5.1. Controls (Controlli)

I controlli sono campi di intestazione della richiesta che dirigono la gestione specifica della richiesta.

5.1.1. Expect (Aspettativa)

Il campo di intestazione Expect in una richiesta indica un determinato insieme di comportamenti (aspettative) che devono essere supportati dal server per gestire correttamente questa richiesta. L'unica aspettativa definita da questa specifica è 100-continue.

Expect = "100-continue"

Il valore del campo Expect non distingue tra maiuscole e minuscole.

Un server che riceve un valore del campo Expect diverso da 100-continue può rispondere con un codice di stato 417 (Expectation Failed) per indicare che l'aspettativa inattesa non può essere soddisfatta.

Un'aspettativa 100-continue informa i destinatari che il client sta per inviare un corpo del messaggio (presumibilmente grande) in questa richiesta e desidera ricevere una risposta provvisoria 100 (Continue) se il metodo, l'URI target e i campi di intestazione non sono sufficienti a causare una risposta immediata di successo, reindirizzamento o errore. Ciò consente al client di attendere un'indicazione che valga la pena inviare il corpo del messaggio prima di farlo effettivamente, il che può migliorare l'efficienza quando il corpo del messaggio è grande o quando il client prevede che un errore sia probabile (ad esempio, quando si invia un metodo che cambia lo stato, per la prima volta, senza credenziali di autenticazione precedentemente verificate).

Ad esempio:

Expect: 100-continue

Un client che invia un'aspettativa 100-continue non è tenuto ad attendere per un periodo di tempo specifico; tale client può (MAY) procedere a inviare il corpo del messaggio anche se non ha ancora ricevuto una risposta. Inoltre, poiché le risposte 100 (Continue) non possono essere inviate attraverso un intermediario HTTP/1.0, tale client non dovrebbe (SHOULD NOT) attendere indefinitamente prima di inviare il corpo del messaggio.

Requisiti per i client:

• Un client non deve (MUST NOT) generare un'aspettativa 100-continue in una richiesta che non include un corpo del messaggio.

Requisiti per i server:

• Un server che riceve un'aspettativa 100-continue in una richiesta HTTP/1.0 deve (MUST) ignorare tale aspettativa.
• Un server può (MAY) omettere l'invio di una risposta 100 (Continue) se ha già ricevuto parte o tutto il corpo del messaggio per la richiesta corrispondente, o se il framing indica che non c'è corpo del messaggio.
• Un server che invia una risposta 100 (Continue) deve (MUST) alla fine inviare un codice di stato finale, una volta che il corpo del messaggio è ricevuto ed elaborato, a meno che la connessione non venga chiusa prematuramente.
• Un server che risponde con un codice di stato finale prima di leggere l'intero corpo del messaggio dovrebbe (SHOULD) indicare in quella risposta se intende chiudere la connessione o continuare a leggere e scartare il messaggio di richiesta (vedere Section 6.6 di [RFC7230]).

5.1.2. Max-Forwards (Inoltri massimi)

Il campo di intestazione Max-Forwards fornisce un meccanismo con i metodi di richiesta TRACE (Section 4.3.8) e OPTIONS (Section 4.3.7) per limitare il numero di volte in cui la richiesta viene inoltrata dai proxy. Ciò può essere utile quando il client sta tentando di tracciare una richiesta che sembra fallire o ciclare a metà della catena.

Max-Forwards = 1*DIGIT

Il valore Max-Forwards è un intero decimale che indica il numero rimanente di volte in cui questo messaggio di richiesta può essere inoltrato.

Ogni intermediario che riceve una richiesta TRACE o OPTIONS contenente un campo di intestazione Max-Forwards deve (MUST) controllare e aggiornare il suo valore prima di inoltrare la richiesta. Se il valore ricevuto è zero (0), l'intermediario non deve (MUST NOT) inoltrare la richiesta; invece, l'intermediario deve (MUST) rispondere come destinatario finale. Se il valore Max-Forwards ricevuto è maggiore di zero, l'intermediario deve (MUST) generare un campo Max-Forwards aggiornato nel messaggio inoltrato con un valore di campo che è il minore tra a) il valore ricevuto decrementato di uno (1) o b) il valore massimo supportato dal destinatario.

Un destinatario può (MAY) ignorare un campo di intestazione Max-Forwards ricevuto con qualsiasi altro metodo di richiesta.

Esempio:

Max-Forwards: 10

5.2. Conditionals (Condizionali)

I campi di intestazione di richiesta condizionale HTTP [RFC7232] consentono a un client di porre una precondizione sullo stato della risorsa target, in modo che l'azione corrispondente alla semantica del metodo non venga applicata se la precondizione viene valutata come falsa. Ogni precondizione definita da questa specifica consiste in un confronto tra un insieme di validatori ottenuti da rappresentazioni precedenti della risorsa target e lo stato attuale dei validatori per la rappresentazione selezionata (Section 7.2 di [RFC7232]). Pertanto, queste precondizioni valutano se lo stato della risorsa target è cambiato da uno stato noto al client. L'effetto di tale valutazione dipende dalla semantica del metodo e dalla scelta del condizionale, come definito nella Section 5 di [RFC7232].

5.3. Content Negotiation (Negoziazione dei contenuti)

I seguenti campi di intestazione della richiesta possono essere inviati da un user agent per impegnarsi nella negoziazione proattiva del contenuto della risposta, come definito nella Section 3.4.1. 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 all'interno del protocollo.

5.3.1. Quality Values (Valori di qualità)

Molti dei campi di intestazione della richiesta per la negoziazione proattiva utilizzano un parametro comune, denominato "q" (senza distinzione tra maiuscole e minuscole), per assegnare un "peso" relativo alla preferenza per quel tipo di contenuto associato. Questo peso è chiamato "valore di qualità" (o "qvalue") perché lo stesso nome di parametro viene spesso utilizzato nelle configurazioni del server per assegnare un peso alla qualità di 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 non è presente alcun parametro "q", 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 nello stesso modo.

Esempi:

Accept: text/html;q=1, application/json;q=0.8
Accept-Language: en-US;q=0.9, fr;q=0.7

5.3.2. Accept (Accettare)

Il campo di intestazione Accept può essere utilizzato dagli user agent per specificare i tipi di media di risposta accettabili. I campi di intestazione Accept possono essere utilizzati per indicare che la richiesta è specificamente limitata a un piccolo insieme di tipi desiderati, come nel caso di una richiesta per un'immagine in linea.

Accept = #( media-range [ accept-params ] )

media-range    = ( "*/*"
                 / ( type "/" "*" )
                 / ( type "/" subtype )
                 ) *( OWS ";" OWS parameter )
accept-params  = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

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 del tipo di media applicabili a quell'intervallo.

Ogni media-range può essere seguito da zero o più parametri del tipo di media applicabili (ad esempio, charset), un parametro "q" facoltativo per indicare un peso relativo (Section 5.3.1), e quindi zero o più parametri di estensione. Il parametro "q" è necessario se sono presenti estensioni (accept-ext), in modo che non vengano confuse con i parametri del tipo di media.

L'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 dell'80% nella qualità."

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 sostituiti 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 è determinato trovando l'intervallo di media con la precedenza più alta che corrisponde al tipo. Ad esempio,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
        text/html;level=2;q=0.4, */*;q=0.5

farebbe sì che i seguenti valori vengano associati:

Tipo di media	Valore di qualità
text/html;level=1	1
text/html	0.7
text/plain	0.3
image/jpeg	0.5
text/html;level=2	0.4
text/html;level=3	0.7

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

5.3.3. Accept-Charset (Accettare-Set di caratteri)

Il campo di intestazione Accept-Charset può essere inviato da un user agent per indicare quali set di caratteri sono accettabili nel contenuto di risposta testuale. Questo campo consente agli user agent in grado di comprendere set di caratteri più completi o per scopi speciali di segnalare tale capacità a un server di origine in grado di rappresentare informazioni in quei set di caratteri.

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

I nomi dei set di caratteri sono definiti nella Section 3.1.1.2. Un 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 Section 5.3.1. Un esempio è

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

Il valore speciale "", se presente nel campo Accept-Charset, corrisponde a ogni set di caratteri non menzionato altrove nel campo Accept-Charset. Se non è presente "" in un campo Accept-Charset, allora qualsiasi set di caratteri non esplicitamente menzionato nel campo è considerato "non accettabile" per il client.

Una richiesta senza alcun campo di intestazione Accept-Charset implica che l'user agent accetterà qualsiasi set di caratteri in risposta. La maggior parte degli user agent generici non invia Accept-Charset, a meno che non siano specificamente configurati per farlo, perché un elenco dettagliato di set di caratteri supportati rende più facile per un server identificare un individuo in virtù di preferenze insolite (localizzate).

Se un campo di intestazione Accept-Charset è presente in una richiesta e nessuna delle rappresentazioni disponibili per la risposta ha un set di caratteri elencato come accettabile, il server di origine può onorare il campo di intestazione, inviando una risposta 406 (Not Acceptable), o ignorare il campo di intestazione trattando la risorsa come se non fosse soggetta a negoziazione dei contenuti.

5.3.4. Accept-Encoding (Accettare-Codifica)

Il campo di intestazione Accept-Encoding può essere utilizzato dagli user agent per indicare quali codifiche di contenuto della risposta (Section 3.1.2.1) sono accettabili nella risposta. Un 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 Section 5.3.1. Il simbolo asterisco "*" in un campo Accept-Encoding corrisponde a qualsiasi codifica di contenuto disponibile non esplicitamente elencata nel campo di intestazione.

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

Una richiesta senza un campo di intestazione Accept-Encoding implica che l'user agent non ha preferenze riguardo alle codifiche di contenuto. Sebbene ciò consenta al server di utilizzare qualsiasi codifica di contenuto in una risposta, non implica che l'user agent sarà in grado di elaborare correttamente tutte le codifiche.

Un server testa se una codifica di contenuto per una data rappresentazione è accettabile utilizzando queste regole:

1. Se non è presente alcun campo Accept-Encoding nella richiesta, qualsiasi codifica di contenuto è considerata accettabile dall'user agent.

2. Se la rappresentazione non ha codifica di contenuto, allora è accettabile per impostazione predefinita a meno che non sia specificamente esclusa dal campo Accept-Encoding che indica "identity;q=0" o "*;q=0" senza una voce più specifica per "identity".

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

4. Se sono accettabili più codifiche di contenuto, allora la codifica di contenuto accettabile con il qvalue non zero più alto è preferita.

Un campo di intestazione Accept-Encoding con un valore di campo combinato vuoto implica che l'user agent non desidera alcuna codifica di contenuto in risposta. Se un campo di intestazione Accept-Encoding è 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.

Nota: La maggior parte delle applicazioni HTTP/1.0 non riconosce né obbedisce ai qvalue associati alle codifiche di contenuto. Ciò significa che i qvalue potrebbero non funzionare e non sono consentiti con x-gzip o x-compress.

5.3.5. Accept-Language (Accettare-Lingua)

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

Accept-Language = 1#( 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 Section 5.3.1. 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."

Una richiesta senza alcun campo di intestazione Accept-Language implica che l'user agent accetterà qualsiasi lingua in risposta. Se il campo di intestazione è presente in una richiesta e nessuna delle rappresentazioni disponibili per la risposta ha un tag linguistico corrispondente, il server di origine può ignorare il campo di intestazione trattando la risorsa come se non fosse soggetta a negoziazione dei contenuti o onorare il campo di intestazione inviando una risposta 406 (Not Acceptable). Tuttavia, quest'ultimo non è incoraggiato, poiché ciò può impedire agli utenti di accedere a contenuti che potrebbero essere in grado di utilizzare (con software di traduzione, ad esempio).

Si noti che alcuni destinatari trattano l'ordine in cui i tag linguistici 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ò basare su questo comportamento. Per coerenza e per massimizzare l'interoperabilità, molti user agent assegnano valori di qualità univoci a ciascun tag linguistico.

Una discussione aggiuntiva sulle liste di priorità linguistiche può essere trovata nella Section 2.3 di [RFC4647].

5.4. Authentication Credentials (Credenziali di autenticazione)

Due campi di intestazione vengono utilizzati per trasportare credenziali di autenticazione, come definito nell'autenticazione HTTP [RFC7235]. Si noti che vari meccanismi personalizzati per l'autenticazione dell'utente utilizzano il campo di intestazione Cookie per questo scopo, come definito in [RFC6265].

5.4.1. Authorization (Autorizzazione)

Il campo di intestazione Authorization consente a un user agent di autenticarsi con un server di origine -- di solito, ma non necessariamente, dopo aver ricevuto una risposta 401 (Unauthorized). Il suo valore consiste in credenziali contenenti le informazioni di autenticazione dell'user agent per il realm della risorsa richiesta.

Authorization = credentials

Se una richiesta è autenticata e un realm è specificato, si presume che le stesse credenziali siano valide per tutte le altre richieste all'interno di questo realm (supponendo che lo schema di autenticazione stesso non richieda diversamente, come credenziali che variano in base a un valore di challenge o utilizzando orologi sincronizzati).

Un proxy che inoltra una richiesta non deve (MUST NOT) modificare alcun campo Authorization in quella richiesta. Vedere Section 3.2 di [RFC7235] per i dettagli.

Affinché un user agent invii credenziali che contengono una password, deve sapere che la connessione al server di origine è sicura. Vedere Section 9.4 per le considerazioni sulla sicurezza correlate.

5.4.2. Proxy-Authorization (Autorizzazione-Proxy)

Il campo di intestazione Proxy-Authorization consente al client di identificarsi (o il suo utente) a un proxy che richiede l'autenticazione. Il suo valore consiste in credenziali contenenti le informazioni di autenticazione del client per il proxy e/o il realm della risorsa richiesta.

Proxy-Authorization = credentials

A differenza di Authorization, il campo di intestazione Proxy-Authorization si applica solo al proxy in ingresso successivo che ha richiesto l'autenticazione utilizzando il campo Proxy-Authenticate. Quando vengono utilizzati più proxy in una catena, il campo di intestazione Proxy-Authorization viene consumato dal primo proxy in ingresso che si aspettava di ricevere credenziali. Un proxy può (MAY) inoltrare le credenziali dalla richiesta del client al proxy successivo se questo è il meccanismo attraverso il quale i proxy autenticano cooperativamente una determinata richiesta.

5.5. Request Context (Contesto della richiesta)

I seguenti campi di intestazione della richiesta forniscono informazioni aggiuntive sul contesto della richiesta, incluse informazioni sull'utente, sull'user agent e sulla risorsa dietro la richiesta.

5.5.1. From (Da)

Il campo di intestazione From contiene un indirizzo email Internet per un utente umano che controlla l'user agent richiedente. L'indirizzo dovrebbe essere utilizzabile dalla macchina, come definito da "mailbox" nella Section 3.4 di [RFC5322].

From = mailbox

Un esempio è:

From: [email protected]

Il campo di intestazione From viene raramente inviato da user agent non robotici. Un user agent non dovrebbe (SHOULD NOT) inviare un campo di intestazione From senza configurazione esplicita da parte dell'utente, poiché ciò potrebbe essere in conflitto con gli interessi di privacy dell'utente o con la politica di sicurezza del suo sito.

Un user agent robotico dovrebbe (SHOULD) inviare un campo di intestazione From valido in modo che la persona responsabile dell'esecuzione del robot possa essere contattata se si verificano problemi sui server, ad esempio se il robot sta inviando richieste eccessive, indesiderate o non valide.

Un server non dovrebbe (SHOULD NOT) utilizzare il campo di intestazione From per il controllo degli accessi o l'autenticazione, poiché la maggior parte dei destinatari presumerà che il valore del campo sia informazione pubblica.

5.5.2. Referer (Referente)

Il campo di intestazione Referer [sic] consente all'user agent di specificare un riferimento URI per la risorsa da cui è stato ottenuto l'URI target (cioè, il "referrer", sebbene il nome del campo sia scritto in modo errato). Un user agent non deve (MUST NOT) includere i componenti fragment e userinfo del riferimento URI [RFC3986], se presenti, quando genera il valore del campo Referer.

Referer = absolute-URI / partial-URI

Il campo di intestazione Referer consente ai server di generare collegamenti inversi ad altre risorse per analisi semplici, registrazione, caching ottimizzato, ecc. Consente anche di trovare collegamenti obsoleti o digitati in modo errato per la manutenzione. Alcuni server utilizzano il campo di intestazione Referer come mezzo per negare collegamenti da altri siti (cosiddetto "deep linking") o limitare la falsificazione di richieste cross-site (CSRF), ma non tutte le richieste lo contengono.

Esempio:

Referer: http://www.example.org/hypertext/Overview.html

Se l'URI target è stato ottenuto da una fonte che non ha un proprio URI (ad esempio, input dalla tastiera dell'utente o una voce nei segnalibri/preferiti dell'utente), l'user agent deve (MUST) escludere il campo Referer o inviarlo con un valore di "about:blank".

Il campo Referer ha il potenziale per rivelare informazioni sul contesto della richiesta o sulla cronologia di navigazione dell'utente, il che è un problema di privacy se l'identificatore della risorsa referente rivela informazioni personali (come un nome account) o una risorsa che dovrebbe essere riservata (come dietro un firewall o interna a un servizio protetto). La maggior parte degli user agent generici non invia il campo di intestazione Referer quando la risorsa referente è un URI locale "file" o "data". Un user agent non deve (MUST NOT) inviare un campo di intestazione Referer in una richiesta HTTP non sicura se la pagina referente è stata ricevuta con un protocollo sicuro. Vedere Section 9.4 per ulteriori considerazioni sulla sicurezza.

Alcuni intermediari sono noti per rimuovere indiscriminatamente i campi di intestazione Referer dalle richieste in uscita. Ciò ha l'effetto collaterale sfortunato di interferire con la protezione contro gli attacchi CSRF, che possono essere molto più dannosi per i loro utenti. Gli intermediari e le estensioni dell'user agent che desiderano limitare la divulgazione di informazioni in Referer dovrebbero limitare le loro modifiche a modifiche specifiche, come la sostituzione di nomi di dominio interni con pseudonimi o il troncamento dei componenti query e/o path. Un intermediario non dovrebbe (SHOULD NOT) modificare o eliminare il campo di intestazione Referer quando il valore del campo condivide lo stesso schema e host del target della richiesta.

5.5.3. TE (Codifica di trasferimento)

Il campo di intestazione TE indica quali codifiche di trasferimento, oltre a chunked, il client è disposto ad accettare in risposta, e se il client è disposto ad accettare campi trailer in una codifica di trasferimento chunked.

Il valore del campo TE consiste in un elenco separato da virgole di nomi di codifica di trasferimento, ciascuno che consente parametri opzionali (come descritto nella Section 4 di [RFC7230]), e/o la parola chiave "trailers".

TE        = #( t-codings )
t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
t-ranking = OWS ";" OWS "q=" rank
rank      = ( "0" [ "." 0*3DIGIT ] )
          / ( "1" [ "." 0*3("0") ] )

Tre esempi di utilizzo di TE sono riportati di seguito.

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Il campo di intestazione TE si applica solo alla connessione immediata. Pertanto, la parola chiave "TE" deve (MUST) essere fornita all'interno di un campo di intestazione Connection (Section 6.1 di [RFC7230]) ogni volta che TE è presente in un messaggio HTTP/1.1.

Un server testa se una codifica di trasferimento è accettabile utilizzando le stesse regole di Accept-Encoding (Section 5.3.4), tranne che la codifica denominata "trailers" è sempre accettabile e una codifica di trasferimento con un valore del parametro "q" di 0 non è accettabile.

Poiché il campo di intestazione TE si applica solo alla connessione immediata, un mittente di TE deve (MUST) anche inviare un'opzione di connessione "TE" all'interno del campo di intestazione Connection (Section 6.1 di [RFC7230]) per impedire che il campo TE venga inoltrato da intermediari che non supportano la sua semantica.

5.5.4. User-Agent (Agente utente)

Il campo di intestazione User-Agent contiene informazioni sull'user agent che ha originato la richiesta, che viene spesso utilizzato dai server per aiutare a identificare l'ambito dei problemi di interoperabilità segnalati, per aggirare o adattare le risposte per evitare particolari limitazioni dell'user agent e per analisi riguardanti l'uso del browser o del sistema operativo. Un user agent dovrebbe (SHOULD) inviare un campo User-Agent in ogni richiesta a meno che non sia specificamente configurato per non farlo.

User-Agent = product *( RWS ( product / comment ) )

Il valore del campo User-Agent consiste in uno o più identificatori di prodotto, ciascuno seguito da zero o più commenti (Section 3.2 di [RFC7230]), che insieme identificano il software dell'user agent e i suoi sottoprodotti significativi. Per convenzione, gli identificatori di prodotto sono elencati in ordine decrescente della loro importanza per identificare il software dell'user agent. Ogni identificatore di prodotto consiste in un nome e una versione opzionale, come definito nella Section 5.5.3 di [RFC7230].

Esempio:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Un user agent non dovrebbe (SHOULD NOT) generare un campo User-Agent contenente dettagli inutilmente dettagliati e dovrebbe (SHOULD) limitare l'aggiunta di sottoprodotti da parte di terzi. Valori del campo User-Agent eccessivamente lunghi e dettagliati aumentano la latenza della richiesta e il rischio che un utente venga identificato contro la sua volontà ("fingerprinting").

Allo stesso modo, le implementazioni sono incoraggiate a non utilizzare i token di prodotto di altre implementazioni per dichiarare compatibilità con esse, poiché ciò aggira lo scopo del campo. Se un user agent si maschera come un user agent diverso, i destinatari possono presumere che l'utente desideri intenzionalmente vedere risposte personalizzate per quell'user agent identificato, anche se potrebbero non funzionare altrettanto bene per l'user agent effettivo utilizzato.

---