10. Contesto del Messaggio (Message Context)

10.1. Campi di Contesto della Richiesta (Request Context Fields)

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

10.1.1. Expect

Il campo di intestazione "Expect" in una richiesta indica un certo insieme di comportamenti (aspettative) che devono essere supportati dal server per gestire correttamente questa richiesta.

Expect =      #expectation
expectation = token [ "=" ( token / quoted-string ) parameters ]

Il valore del campo Expect non è case-sensitive.

L'unica aspettativa definita da questa specifica è "100-continue" (senza parametri definiti).

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

L'aspettativa "100-continue" informa i destinatari che il client sta per inviare contenuto (presumibilmente grande) in questa richiesta e desidera ricevere una risposta intermedia 100 (Continue) se il metodo, l'URI di destinazione e i campi di intestazione non sono sufficienti a causare una risposta di successo, reindirizzamento o errore immediata. Ciò consente al client di attendere un'indicazione che vale la pena inviare il contenuto prima di farlo effettivamente, il che può migliorare l'efficienza quando i dati sono enormi o quando il client prevede che sia probabile un errore (ad esempio, quando si invia un metodo di cambiamento di stato, senza credenziali di autenticazione precedentemente verificate).

Ad esempio, una richiesta che inizia con

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue

consente al server di origine di rispondere immediatamente con un messaggio di errore, come 401 (Unauthorized) o 405 (Method Not Allowed), prima che il client inizi a riempire le pipe con un trasferimento di dati non necessario.

Requisiti per i client:

• Un client NON DEVE (MUST NOT) generare un'aspettativa 100-continue in una richiesta che non include contenuto.
• Un client che attenderà una risposta 100 (Continue) prima di inviare il contenuto della richiesta DEVE (MUST) inviare un campo di intestazione Expect contenente un'aspettativa 100-continue.
• Un client che invia un'aspettativa 100-continue non è tenuto ad attendere alcuna durata specifica; un tale client PUÒ (MAY) procedere a inviare il contenuto anche se non ha ancora ricevuto una risposta. Inoltre, poiché le risposte 100 (Continue) non possono essere inviate attraverso un intermediario HTTP/1.0, un tale client NON DOVREBBE (SHOULD NOT) attendere indefinitamente prima di inviare il contenuto.
• Un client che riceve un codice di stato 417 (Expectation Failed) in risposta a una richiesta contenente un'aspettativa 100-continue DOVREBBE (SHOULD) ripetere quella richiesta senza aspettativa 100-continue, poiché la risposta 417 indica semplicemente che la catena di risposta non supporta le aspettative (ad esempio, passa attraverso un server HTTP/1.0).

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 di inviare una risposta 100 (Continue) se ha già ricevuto parte o tutto il contenuto per la richiesta corrispondente, o se il framing indica che non c'è contenuto.
• Un server che invia una risposta 100 (Continue) DEVE (MUST) infine inviare un codice di stato finale, una volta ricevuto ed elaborato il contenuto della richiesta, a meno che la connessione non venga chiusa prematuramente.
• Un server che risponde con un codice di stato finale prima di leggere l'intero contenuto della richiesta DOVREBBE (SHOULD) indicare se intende chiudere la connessione (ad esempio, vedere Sezione 9.6 di [HTTP/1.1]) o continuare a leggere il contenuto della richiesta.

Al ricevimento di una richiesta HTTP/1.1 (o successiva) che ha un metodo, URI di destinazione e sezione di intestazione completa che contiene un'aspettativa 100-continue e indica che seguirà un contenuto di richiesta, un server di origine DEVE (MUST) inviare:

• una risposta immediata con un codice di stato finale, se tale stato può essere determinato esaminando solo il metodo, l'URI di destinazione e i campi di intestazione, o
• una risposta immediata 100 (Continue) per incoraggiare il client a inviare il contenuto della richiesta.

Il server di origine NON DEVE (MUST NOT) attendere il contenuto prima di inviare la risposta 100 (Continue).

Al ricevimento di una richiesta HTTP/1.1 (o successiva) che ha un metodo, URI di destinazione e sezione di intestazione completa che contiene un'aspettativa 100-continue e indica che seguirà un contenuto di richiesta, un proxy DEVE (MUST):

• inviare una risposta immediata con un codice di stato finale, se tale stato può essere determinato esaminando solo il metodo, l'URI di destinazione e i campi di intestazione, o
• inoltrare la richiesta verso il server di origine inviando una riga di richiesta e una sezione di intestazione corrispondenti al successivo server in entrata.

Se il proxy crede (dalla configurazione o dall'interazione passata) che il successivo server in entrata supporti solo HTTP/1.0, il proxy PUÒ (MAY) generare una risposta immediata 100 (Continue) per incoraggiare il client a iniziare a inviare il contenuto.

10.1.2. From

Il campo di intestazione "From" contiene un indirizzo e-mail Internet per un utente umano che controlla lo user agent richiedente. L'indirizzo dovrebbe essere utilizzabile da macchina, come definito da "mailbox" nella Sezione 3.4 di [RFC5322]:

From    = mailbox

mailbox = <mailbox, see [RFC5322], Section 3.4>

Un esempio è:

From: [email protected]

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

Uno 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 invia 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é il suo valore è previsto essere visibile a chiunque riceva o osservi la richiesta e viene solitamente registrato nei file di log e nei rapporti di errore senza alcuna aspettativa di privacy.

10.1.3. Referer

Il campo di intestazione "Referer" [sic] consente allo user agent di specificare un riferimento URI per la risorsa da cui è stato ottenuto l'URI di destinazione (cioè, il "referrer", sebbene il nome del campo sia scritto erroneamente). Uno user agent NON DEVE (MUST NOT) includere i componenti fragment e userinfo del riferimento URI [URI], se presenti, quando genera il valore del campo Referer.

Referer = absolute-URI / partial-URI

Il valore del campo è un absolute-URI o un partial-URI. Nel secondo caso (Sezione 4), l'URI riferito è relativo all'URI di destinazione ([URI], Sezione 5).

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

Esempio:

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

Se l'URI di destinazione è 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), lo user agent DEVE (MUST) escludere il campo di intestazione Referer o inviarlo con un valore di "about:blank".

Il valore del campo di intestazione Referer non deve necessariamente trasmettere l'URI completo della risorsa di riferimento; uno user agent PUÒ (MAY) troncare parti diverse dall'origine di riferimento.

Il campo di intestazione Referer ha il potenziale di rivelare informazioni sul contesto della richiesta o sulla cronologia di navigazione dell'utente, il che costituisce un problema di privacy se l'identificatore della risorsa di riferimento rivela informazioni personali (come un nome di account) o una risorsa che dovrebbe essere confidenziale (come dietro un firewall o all'interno di un servizio sicuro). La maggior parte degli user agent general-purpose non invia il campo di intestazione Referer quando la risorsa di riferimento è un URI "file" o "data" locale. Uno user agent NON DOVREBBE (SHOULD NOT) inviare un campo di intestazione Referer se la risorsa di riferimento è stata acceduta con un protocollo sicuro e l'origine del target della richiesta differisce da quella della risorsa di riferimento, a meno che la risorsa di riferimento non consenta esplicitamente l'invio del Referer. Uno user agent NON DEVE (MUST NOT) inviare un campo di intestazione Referer in una richiesta HTTP non sicura se la risorsa di riferimento è stata acceduta con un protocollo sicuro. Vedere Sezione 17.9 per ulteriori considerazioni sulla sicurezza.

È noto che alcuni intermediari rimuovono 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 può essere molto più dannosa per i loro utenti. Gli intermediari e le estensioni dello 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 di query e/o percorso. 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.

10.1.4. TE

Il campo di intestazione "TE" descrive le capacità del client riguardo alle codifiche di trasferimento e alle sezioni trailer.

Come descritto nella Sezione 6.5, l'invio di TE con un membro "trailers" in una richiesta indica che il client non scarterà i campi trailer.

TE è utilizzato anche in HTTP/1.1 per informare i server su quali codifiche di trasferimento il client è in grado di accettare nella risposta. Al momento della pubblicazione, solo HTTP/1.1 utilizza le codifiche di trasferimento (vedere Sezione 7 di [HTTP/1.1]).

Il valore del campo TE è un elenco di membri, ogni membro (a parte "trailers") composto da un token di nome di codifica di trasferimento con un peso opzionale che indica la preferenza relativa del client per quella codifica di trasferimento (Sezione 12.4.2) e parametri opzionali per quella codifica di trasferimento.

TE                 = #t-codings
t-codings          = "trailers" / ( transfer-coding [ weight ] )
transfer-coding    = token *( OWS ";" OWS transfer-parameter )
transfer-parameter = token BWS "=" BWS ( token / quoted-string )

Un mittente di TE DEVE (MUST) anche inviare un'opzione di connessione "TE" nel campo di intestazione Connection (Sezione 7.6.1) per impedire che il campo TE venga inoltrato da intermediari che non supportano la sua semantica.

10.1.5. User-Agent

Il campo di intestazione "User-Agent" contiene informazioni sullo 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 personalizzare le risposte per evitare particolari limitazioni dello user agent, e per analisi sull'uso del browser o del sistema operativo. Uno user agent DOVREBBE (SHOULD) inviare un campo di intestazione 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 di uno o più identificatori di prodotto, ciascuno seguito da zero o più commenti (Sezione 5.6.5), che insieme identificano il software dello 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 dello user agent. Ogni identificatore di prodotto consiste di un nome e una versione opzionale.

product         = token ["/" product-version]
product-version = token

Un mittente DOVREBBE (SHOULD) limitare gli identificatori di prodotto generati a ciò che è necessario per identificare il prodotto; un mittente NON DEVE (MUST NOT) generare pubblicità o altre informazioni non essenziali all'interno dell'identificatore di prodotto. Un mittente NON DOVREBBE (SHOULD NOT) generare informazioni in product-version che non siano un identificatore di versione (cioè, versioni successive dello stesso nome di prodotto dovrebbero differire solo nella parte product-version dell'identificatore di prodotto).

Esempio:

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

Uno user agent NON DOVREBBE (SHOULD NOT) generare un campo di intestazione User-Agent contenente dettagli inutilmente granulari e DOVREBBE (SHOULD) limitare l'aggiunta di sottoprodotti da parte di terzi. Valori del campo User-Agent eccessivamente lunghi e dettagliati aumentano la latenza delle richieste 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 la compatibilità con esse, poiché ciò elude lo scopo del campo. Se uno user agent si maschera come uno user agent diverso, i destinatari possono presumere che l'utente desideri intenzionalmente vedere risposte personalizzate per quello user agent identificato, anche se potrebbero non funzionare altrettanto bene per lo user agent effettivamente utilizzato.

10.2. Campi di Contesto della Risposta (Response Context Fields)

I seguenti campi di intestazione della risposta forniscono informazioni aggiuntive sulla risposta, oltre a quanto implicato dal codice di stato, incluse informazioni sul server, sulla risorsa di destinazione o sulle risorse correlate.

10.2.1. Allow

Il campo di intestazione "Allow" elenca l'insieme di metodi pubblicizzati come supportati dalla risorsa di destinazione. Lo scopo di questo campo è strettamente quello di informare il destinatario dei metodi di richiesta validi associati alla risorsa.

Allow = #method

Esempio di utilizzo:

Allow: GET, HEAD, PUT

L'insieme effettivo di metodi consentiti è definito dal server di origine al momento di ogni richiesta. Un server di origine DEVE (MUST) generare un campo di intestazione Allow in una risposta 405 (Method Not Allowed) e PUÒ (MAY) farlo in qualsiasi altra risposta. Un valore del campo Allow vuoto indica che la risorsa non consente alcun metodo, il che potrebbe verificarsi in una risposta 405 se la risorsa è stata temporaneamente disabilitata dalla configurazione.

Un proxy NON DEVE (MUST NOT) modificare il campo di intestazione Allow -- non ha bisogno di comprendere tutti i metodi indicati per gestirli secondo le regole generali di elaborazione dei messaggi.

10.2.2. Location

Il campo di intestazione "Location" è utilizzato in alcune risposte per fare riferimento a una risorsa specifica in relazione alla risposta. Il tipo di relazione è definito dalla combinazione del metodo di richiesta e della semantica del codice di stato.

Location = URI-reference

Il valore del campo consiste di un singolo URI-reference. Quando ha la forma di un riferimento relativo ([URI], Sezione 4.2), il valore finale viene calcolato risolvendolo rispetto all'URI di destinazione ([URI], Sezione 5).

Per le risposte 201 (Created), il valore Location fa riferimento alla risorsa principale creata dalla richiesta. Per le risposte 3xx (Redirection), il valore Location fa riferimento alla risorsa di destinazione preferita per reindirizzare automaticamente la richiesta.

Se il valore Location fornito in una risposta 3xx (Redirection) non ha un componente fragment, uno user agent DEVE (MUST) elaborare il reindirizzamento come se il valore ereditasse il componente fragment del riferimento URI utilizzato per generare l'URI di destinazione (cioè, il reindirizzamento eredita il fragment del riferimento originale, se presente).

Ad esempio, una richiesta GET generata per il riferimento URI "http://www.example.org/~tim" potrebbe risultare in una risposta 303 (See Other) contenente il campo di intestazione:

Location: /People.html#tim

che suggerisce allo user agent di reindirizzare a "http://www.example.org/People.html#tim"

Allo stesso modo, una richiesta GET generata per il riferimento URI "http://www.example.org/index.html#larry" potrebbe risultare in una risposta 301 (Moved Permanently) contenente il campo di intestazione:

Location: http://www.example.net/index.html

che suggerisce allo user agent di reindirizzare a "http://www.example.net/index.html#larry", preservando l'identificatore di fragment originale.

Ci sono circostanze in cui un identificatore di fragment in un valore Location non sarebbe appropriato. Ad esempio, il campo di intestazione Location in una risposta 201 (Created) dovrebbe fornire un URI specifico per la risorsa creata.

Nota: Alcuni destinatari tentano di recuperare da campi di intestazione Location che non sono riferimenti URI validi. Questa specifica non impone né definisce tale elaborazione, ma la consente per motivi di robustezza. Un valore del campo Location non può consentire un elenco di membri, poiché il separatore di elenco con virgola è un dato valido all'interno di un URI-reference. Se viene inviato un messaggio non valido con più righe di campo Location, un destinatario lungo il percorso potrebbe combinare quelle righe di campo in un unico valore. Il recupero di un valore del campo Location valido da tale situazione è difficile e non interoperabile tra le implementazioni.

Nota: Il campo di intestazione Content-Location (Sezione 8.7) differisce da Location in quanto Content-Location fa riferimento alla risorsa più specifica corrispondente alla rappresentazione inclusa. È quindi possibile che una risposta contenga sia i campi di intestazione Location che Content-Location.

10.2.3. Retry-After

I server inviano il campo di intestazione "Retry-After" per indicare quanto tempo lo user agent dovrebbe attendere prima di effettuare una richiesta di follow-up. Quando inviato con una risposta 503 (Service Unavailable), Retry-After indica per quanto tempo il servizio dovrebbe essere non disponibile per il client. Quando inviato con qualsiasi risposta 3xx (Redirection), Retry-After indica il tempo minimo che lo user agent è invitato ad attendere prima di emettere la richiesta reindirizzata.

Il valore del campo Retry-After può essere una HTTP-date o un numero di secondi di ritardo dopo aver ricevuto la risposta.

Retry-After = HTTP-date / delay-seconds

Un valore delay-seconds è un intero decimale non negativo, che rappresenta il tempo in secondi.

delay-seconds  = 1*DIGIT

Due esempi del suo utilizzo sono

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

Nell'ultimo esempio, il ritardo è di 2 minuti.

10.2.4. Server

Il campo di intestazione "Server" contiene informazioni sul software utilizzato dal server di origine per gestire la richiesta, che viene spesso utilizzato dai client per aiutare a identificare l'ambito dei problemi di interoperabilità segnalati, per aggirare o personalizzare le richieste per evitare particolari limitazioni del server, e per analisi sull'uso del server o del sistema operativo. Un server di origine PUÒ (MAY) generare un campo di intestazione Server nelle sue risposte.

Server = product *( RWS ( product / comment ) )

Il valore del campo di intestazione Server consiste di uno o più identificatori di prodotto, ciascuno seguito da zero o più commenti (Sezione 5.6.5), che insieme identificano il software del server di origine e i suoi sottoprodotti significativi. Per convenzione, gli identificatori di prodotto sono elencati in ordine decrescente della loro importanza per identificare il software del server di origine. Ogni identificatore di prodotto consiste di un nome e una versione opzionale, come definito nella Sezione 10.1.5.

Esempio:

Server: CERN/3.0 libwww/2.17

Un server di origine NON DOVREBBE (SHOULD NOT) generare un campo di intestazione Server contenente dettagli inutilmente granulari e DOVREBBE (SHOULD) limitare l'aggiunta di sottoprodotti da parte di terzi. Valori del campo Server eccessivamente lunghi e dettagliati aumentano la latenza delle risposte e potenzialmente rivelano dettagli di implementazione interni che potrebbero rendere (leggermente) più facile per gli aggressori trovare e sfruttare falle di sicurezza note.