14. Header Field Definitions (Definizioni dei Campi di Intestazione)

14 Definizioni dei Campi di Intestazione (Header Field Definitions)

Questa sezione definisce la sintassi e la semantica di tutti i campi di intestazione HTTP/1.1 standard. Per i campi di intestazione di entità (entity-header field), sia il mittente sia il destinatario si riferiscono al client oppure al server, a seconda di chi invia e di chi riceve l'entità.

14.1 Accept

Il campo di intestazione di richiesta Accept può essere usato per specificare determinati tipi di media che sono accettabili per la risposta. Le intestazioni Accept possono essere utilizzate 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         = "Accept" ":"
                        #( media-range [ accept-params ] )

       media-range    = ( "*/*"
                        | ( type "/" "*" )
                        | ( type "/" subtype )
                        ) *( ";" parameter )
       accept-params  = ";" "q" "=" qvalue *( accept-extension )
       accept-extension = ";" token [ "=" ( token | quoted-string ) ]

Il carattere asterisco "" viene usato per raggruppare i tipi di media in intervalli, dove "/" indica tutti i tipi di media e "type/" indica tutti i sottotipi di quel tipo. Il media-range può (MAY) includere parametri di tipo di media applicabili a quell'intervallo.

Ogni media-range può (MAY) essere seguito da uno o più accept-params, che iniziano con il parametro "q" per indicare un fattore di qualità relativo. Il primo parametro "q" (se presente) separa i parametri del media-range dagli accept-params. I fattori di qualità consentono all'utente o all'user agent di indicare il grado relativo di preferenza per quel media-range, usando la scala qvalue da 0 a 1 (sezione 3.9). Il valore predefinito è q=1.

Nota: l'uso del nome di parametro "q" per separare i parametri del tipo di media dai parametri di estensione di Accept deriva da una prassi storica. Sebbene ciò impedisca di usare con un intervallo di media qualsiasi parametro di tipo di media chiamato "q", si ritiene che un simile evento sia improbabile, data l'assenza di parametri "q" nel registro dei tipi di media IANA e il raro utilizzo di parametri di tipo di media in Accept. Si sconsiglia ai tipi di media futuri di registrare un parametro chiamato "q".

L'esempio

       Accept: audio/*; q=0.2, audio/basic

dovrebbe (SHOULD) essere interpretato come "preferisco audio/basic, ma inviami qualsiasi tipo audio se è il migliore disponibile dopo una riduzione dell'80% della qualità".

Se non è presente alcun campo di intestazione Accept, si presume che il client accetti tutti i tipi di media. Se è presente un campo di intestazione Accept e il server non può inviare una risposta accettabile secondo il valore combinato del campo Accept, allora il server dovrebbe (SHOULD) inviare una risposta 406 (not acceptable).

Un esempio più elaborato è

       Accept: text/plain; q=0.5, text/html,
               text/x-dvi; q=0.8, text/x-c

Espresso a parole, questo verrebbe interpretato come "text/html e text/x-c sono i tipi di media preferiti, ma se non esistono, allora invia l'entità text/x-dvi, e se anche questa non esiste, invia l'entità text/plain".

Gli intervalli di media possono essere sovrascritti da intervalli di media più specifici o da tipi di media specifici. Se più di un intervallo di media si applica a un dato tipo, il riferimento più specifico ha la precedenza. Per esempio,

       Accept: text/*, text/html, text/html;level=1, */*

ha la seguente precedenza:

       1) text/html;level=1
       2) text/html
       3) text/*
       4) */*

Il fattore di qualità del tipo di media associato a un dato tipo è determinato individuando l'intervallo di media con la precedenza più alta che corrisponde a quel tipo. Per 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 vengano associati i seguenti valori:

       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 lo user agent non sia un sistema chiuso che non può interagire con altri agenti di rendering, questo insieme predefinito dovrebbe essere configurabile dall'utente.

14.2 Accept-Charset

Il campo di intestazione di richiesta Accept-Charset può essere usato per indicare quali insiemi di caratteri sono accettabili per la risposta. Questo campo consente ai client capaci di comprendere insiemi di caratteri più completi o destinati a scopi speciali di segnalare tale capacità a un server in grado di rappresentare documenti con quegli insiemi di caratteri.

      Accept-Charset = "Accept-Charset" ":"
              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )

I valori degli insiemi di caratteri sono descritti nella sezione 3.4. A ogni charset può (MAY) essere assegnato un valore di qualità associato che rappresenta la preferenza dell'utente per quel charset. Il valore predefinito è q=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 insieme di caratteri (compreso ISO-8859-1) che non sia menzionato altrove nel campo Accept-Charset. Se nel campo Accept-Charset non è presente alcun "", allora tutti gli insiemi di caratteri non esplicitamente menzionati ottengono un valore di qualità pari a 0, a eccezione di ISO-8859-1, che ottiene un valore di qualità pari a 1 se non è menzionato esplicitamente.

Se non è presente alcuna intestazione Accept-Charset, il valore predefinito è che qualsiasi insieme di caratteri è accettabile. Se è presente un'intestazione Accept-Charset e il server non può inviare una risposta accettabile secondo l'intestazione Accept-Charset, allora il server dovrebbe (SHOULD) inviare una risposta di errore con il codice di stato 406 (not acceptable), sebbene sia consentito anche l'invio di una risposta non accettabile.

14.3 Accept-Encoding

Il campo di intestazione di richiesta Accept-Encoding è simile ad Accept, ma limita le codifiche del contenuto (content-coding, sezione 3.5) che sono accettabili nella risposta.

       Accept-Encoding  = "Accept-Encoding" ":"
                          1#( codings [ ";" "q" "=" qvalue ] )
       codings          = ( content-coding | "*" )

Esempi del suo uso sono:

       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

Un server verifica se una codifica del contenuto è accettabile, secondo un campo Accept-Encoding, usando queste regole:

1. Se la content-coding è una delle content-coding elencate nel campo Accept-Encoding, allora è accettabile, a meno che non sia accompagnata da un qvalue pari a 0. (Come definito nella sezione 3.9, un qvalue pari a 0 significa "non accettabile".)

2. Il simbolo speciale "*" in un campo Accept-Encoding corrisponde a qualsiasi content-coding disponibile non elencata esplicitamente nel campo di intestazione.

3. Se più content-coding sono accettabili, viene preferita la content-coding accettabile con il qvalue non nullo più alto.

4. La content-coding "identity" è sempre accettabile, a meno che non venga specificamente rifiutata perché il campo Accept-Encoding include "identity;q=0", oppure perché il campo include "*;q=0" e non include esplicitamente la content-coding "identity". Se il valore del campo Accept-Encoding è vuoto, allora è accettabile solo la codifica "identity".

Se in una richiesta è presente un campo Accept-Encoding e il server non può inviare una risposta accettabile secondo l'intestazione Accept-Encoding, allora il server dovrebbe (SHOULD) inviare una risposta di errore con il codice di stato 406 (Not Acceptable).

Se in una richiesta non è presente alcun campo Accept-Encoding, il server può (MAY) presumere che il client accetti qualsiasi codifica del contenuto. In questo caso, se "identity" è una delle codifiche del contenuto disponibili, allora il server dovrebbe (SHOULD) usare la codifica del contenuto "identity", a meno che non disponga di informazioni aggiuntive secondo cui una diversa codifica del contenuto è significativa per il client.

Nota: se la richiesta non include un campo Accept-Encoding e la codifica del contenuto "identity" non è disponibile, allora si preferiscono le codifiche del contenuto comunemente comprese dai client HTTP/1.0 (cioè "gzip" e "compress"); alcuni client più vecchi visualizzano in modo improprio i messaggi inviati con altre codifiche del contenuto. Il server potrebbe anche prendere questa decisione sulla base di informazioni relative al particolare user-agent o client.

Nota: la maggior parte delle applicazioni HTTP/1.0 non riconosce né rispetta i qvalue associati alle codifiche del contenuto. Ciò significa che i qvalue non funzioneranno e non sono consentiti con x-gzip o x-compress.

14.4 Accept-Language

Il campo di intestazione di richiesta Accept-Language è simile ad Accept, ma limita l'insieme delle lingue naturali preferite come risposta alla richiesta. I tag di lingua (language tag) sono definiti nella sezione 3.10.

       Accept-Language = "Accept-Language" ":"
                         1#( language-range [ ";" "q" "=" qvalue ] )
       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

A ogni language-range può (MAY) essere assegnato un valore di qualità associato, che rappresenta una stima della preferenza dell'utente per le lingue specificate da quell'intervallo. Il valore di qualità è "q=1" per impostazione predefinita. Per 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". Un language-range corrisponde a un language-tag se è esattamente uguale al tag, oppure se è esattamente uguale a un prefisso del tag tale che il primo carattere del tag successivo al prefisso sia "-". L'intervallo speciale "*", se presente nel campo Accept-Language, corrisponde a ogni tag non corrispondente a nessun altro intervallo presente nel campo Accept-Language.

Nota: questo uso della regola di corrispondenza per prefisso non implica che i tag di lingua siano assegnati alle lingue in modo tale che valga sempre che, se un utente comprende una lingua con un certo tag, allora quello stesso utente comprenderà anche tutte le lingue i cui tag hanno quel tag come prefisso. La regola del prefisso consente semplicemente di usare tag di prefisso quando questo è il caso.

Il fattore di qualità della lingua assegnato a un language-tag dal campo Accept-Language è il valore di qualità del language-range più lungo presente nel campo che corrisponde a quel language-tag. Se nessun language-range presente nel campo corrisponde al tag, il fattore di qualità della lingua assegnato è 0. Se nella richiesta non è presente alcuna intestazione Accept-Language, il server dovrebbe (SHOULD) presumere che tutte le lingue siano ugualmente accettabili. Se è presente un'intestazione Accept-Language, allora sono accettabili tutte le lingue a cui è assegnato un fattore di qualità maggiore di 0.

L'invio in ogni richiesta di un'intestazione Accept-Language contenente le preferenze linguistiche complete dell'utente potrebbe essere contrario alle aspettative di privacy dell'utente. Per una discussione di questo problema, vedere la sezione 15.1.4.

Poiché l'intelligibilità dipende fortemente dal singolo utente, si raccomanda che le applicazioni client rendano disponibile all'utente la scelta della preferenza linguistica. Se la scelta non viene resa disponibile, allora il campo di intestazione Accept-Language non deve (MUST NOT) essere fornito nella richiesta.

Nota: nel rendere disponibile all'utente la scelta della preferenza linguistica, ricordiamo agli implementatori che gli utenti non hanno familiarità con i dettagli della corrispondenza tra lingue sopra descritta e che occorre fornire una guida adeguata. Per esempio, gli utenti potrebbero presumere che, selezionando "en-gb", verrà loro servito qualsiasi tipo di documento in inglese qualora l'inglese britannico non sia disponibile. In un caso simile, uno user agent potrebbe suggerire di aggiungere "en" per ottenere il comportamento di corrispondenza migliore.

14.5 Accept-Ranges

Il campo di intestazione di risposta Accept-Ranges consente al server di indicare la propria accettazione delle richieste di intervallo (range request) per una risorsa:

          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
          acceptable-ranges = 1#range-unit | "none"

I server di origine che accettano richieste di intervallo di byte possono (MAY) inviare

          Accept-Ranges: bytes

ma non sono tenuti a farlo. I client possono (MAY) generare richieste di intervallo di byte senza aver ricevuto questa intestazione per la risorsa in questione. Le unità di intervallo (range unit) sono definite nella sezione 3.12.

I server che non accettano alcun tipo di richiesta di intervallo per una risorsa possono (MAY) inviare

          Accept-Ranges: none

per avvisare il client di non tentare una richiesta di intervallo.

14.6 Age

Il campo di intestazione di risposta Age trasmette la stima del mittente del tempo trascorso da quando la risposta (o la sua rivalidazione) è stata generata presso il server di origine. Una risposta in cache è "fresca" (fresh) se la sua età non supera la sua durata di freschezza (freshness lifetime). I valori di Age sono calcolati come specificato nella sezione 13.2.3.

           Age = "Age" ":" age-value
           age-value = delta-seconds

I valori di Age sono interi decimali non negativi, che rappresentano il tempo in secondi.

Se una cache riceve un valore maggiore del più grande intero positivo che è in grado di rappresentare, oppure se uno dei suoi calcoli di età va in overflow, deve (MUST) trasmettere un'intestazione Age con valore 2147483648 (2^31). Un server HTTP/1.1 che include una cache deve (MUST) includere un campo di intestazione Age in ogni risposta generata dalla propria cache. Le cache dovrebbero (SHOULD) usare un tipo aritmetico con almeno 31 bit di intervallo.

14.7 Allow

Il campo di intestazione di entità Allow elenca l'insieme dei metodi supportati dalla risorsa identificata dalla Request-URI. Lo scopo di questo campo è strettamente quello di informare il destinatario dei metodi validi associati alla risorsa. Un campo di intestazione Allow deve (MUST) essere presente in una risposta 405 (Method Not Allowed).

          Allow   = "Allow" ":" #Method

Esempio d'uso:

          Allow: GET, HEAD, PUT

Questo campo non può impedire a un client di provare altri metodi. Tuttavia, le indicazioni fornite dal valore del campo di intestazione Allow dovrebbero (SHOULD) essere seguite. L'insieme effettivo dei metodi consentiti è definito dal server di origine al momento di ogni richiesta.

Il campo di intestazione Allow può (MAY) essere fornito con una richiesta PUT per raccomandare i metodi che la risorsa nuova o modificata dovrebbe supportare. Il server non è tenuto a supportare questi metodi e dovrebbe (SHOULD) includere nella risposta un'intestazione Allow che indichi i metodi effettivamente supportati.

Un proxy non deve (MUST NOT) modificare il campo di intestazione Allow nemmeno se non comprende tutti i metodi specificati, poiché lo user agent potrebbe disporre di altri mezzi per comunicare con il server di origine.

14.8 Authorization

Uno user agent che desidera autenticarsi presso un server — di norma, ma non necessariamente, dopo aver ricevuto una risposta 401 — lo fa includendo nella richiesta un campo di intestazione di richiesta Authorization. Il valore del campo Authorization è costituito da credenziali che contengono le informazioni di autenticazione dello user agent per il realm della risorsa richiesta.

          Authorization  = "Authorization" ":" credentials

L'autenticazione di accesso HTTP è descritta in "HTTP Authentication: Basic and Digest Access Authentication" [43]. Se una richiesta è autenticata e viene specificato un realm, le stesse credenziali dovrebbero (SHOULD) essere valide per tutte le altre richieste all'interno di quel realm (presumendo che lo schema di autenticazione stesso non richieda diversamente, come nel caso di credenziali che variano in base a un valore di challenge o all'uso di orologi sincronizzati).

Quando una cache condivisa (vedere la sezione 13.7) riceve una richiesta contenente un campo Authorization, non deve (MUST NOT) restituire la risposta corrispondente come risposta a qualsiasi altra richiesta, a meno che non sussista una delle seguenti specifiche eccezioni:

1. Se la risposta include la direttiva di cache-control "s-maxage", la cache può (MAY) usare quella risposta per rispondere a una richiesta successiva. Ma (se l'età massima specificata è trascorsa) una cache proxy deve (MUST) prima rivalidarla con il server di origine, usando le intestazioni di richiesta della nuova richiesta per consentire al server di origine di autenticare la nuova richiesta. (Questo è il comportamento definito per s-maxage.) Se la risposta include "s-maxage=0", il proxy deve (MUST) rivalidarla sempre prima di riutilizzarla.

2. Se la risposta include la direttiva di cache-control "must-revalidate", la cache può (MAY) usare quella risposta per rispondere a una richiesta successiva. Ma se la risposta è obsoleta (stale), tutte le cache devono (MUST) prima rivalidarla con il server di origine, usando le intestazioni di richiesta della nuova richiesta per consentire al server di origine di autenticare la nuova richiesta.

3. Se la risposta include la direttiva di cache-control "public", essa può (MAY) essere restituita come risposta a qualsiasi richiesta successiva.

14.9 Cache-Control

Il campo di intestazione generale Cache-Control viene usato per specificare direttive che devono (MUST) essere obbedite da tutti i meccanismi di caching lungo la catena richiesta/risposta. Le direttive specificano comportamenti intesi a impedire che le cache interferiscano negativamente con la richiesta o la risposta. Queste direttive di norma prevalgono sugli algoritmi di caching predefiniti. Le direttive di cache sono unidirezionali, nel senso che la presenza di una direttiva in una richiesta non implica che la stessa direttiva debba essere fornita nella risposta.

Si noti che le cache HTTP/1.0 potrebbero non implementare Cache-Control e potrebbero implementare soltanto Pragma: no-cache (vedere la sezione 14.32).

Le direttive di cache devono (MUST) essere propagate attraverso un'applicazione proxy o gateway, indipendentemente dal loro significato per tale applicazione, poiché le direttive potrebbero essere applicabili a tutti i destinatari lungo la catena richiesta/risposta. Non è possibile specificare una cache-directive per una cache particolare.

    Cache-Control   = "Cache-Control" ":" 1#cache-directive

    cache-directive = cache-request-directive
         | cache-response-directive

    cache-request-directive =
           "no-cache"                          ; Section 14.9.1
         | "no-store"                          ; Section 14.9.2
         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
         | "min-fresh" "=" delta-seconds       ; Section 14.9.3
         | "no-transform"                      ; Section 14.9.5
        | "only-if-cached"                    ; Section 14.9.4
        | cache-extension                     ; Section 14.9.6

    cache-response-directive =
          "public"                               ; Section 14.9.1
        | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
        | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
        | "no-store"                             ; Section 14.9.2
        | "no-transform"                         ; Section 14.9.5
        | "must-revalidate"                      ; Section 14.9.4
         | "proxy-revalidate"                     ; Section 14.9.4
         | "max-age" "=" delta-seconds            ; Section 14.9.3
         | "s-maxage" "=" delta-seconds           ; Section 14.9.3
         | cache-extension                        ; Section 14.9.6

    cache-extension = token [ "=" ( token | quoted-string ) ]

Quando una direttiva appare senza alcun parametro 1#field-name, la direttiva si applica all'intera richiesta o risposta. Quando una tale direttiva appare con un parametro 1#field-name, essa si applica solo al campo o ai campi indicati, e non al resto della richiesta o della risposta. Questo meccanismo supporta l'estensibilità; le implementazioni di versioni future del protocollo HTTP potrebbero applicare queste direttive a campi di intestazione non definiti in HTTP/1.1.

Le direttive di cache-control possono essere suddivise in queste categorie generali:

• Restrizioni su ciò che è memorizzabile in cache (cacheable); queste possono essere imposte solo dal server di origine.

• Restrizioni su ciò che può essere memorizzato da una cache; queste possono essere imposte sia dal server di origine sia dallo user agent.

• Modifiche del meccanismo di scadenza di base; queste possono essere imposte sia dal server di origine sia dallo user agent.

• Controlli sulla rivalidazione e sul ricaricamento della cache; questi possono essere imposti solo da uno user agent.

• Controllo sulla trasformazione delle entità.

• Estensioni al sistema di caching.

14.9.1 What is Cacheable (Cosa è Memorizzabile in Cache)

Per impostazione predefinita, una risposta è memorizzabile in cache (cacheable) se i requisiti del metodo di richiesta, dei campi di intestazione di richiesta e dello stato della risposta indicano che è tale. La sezione 13.4 riassume queste impostazioni predefinite per la cacheability. Le seguenti direttive di risposta Cache-Control consentono a un server di origine di sovrascrivere la cacheability predefinita di una risposta:

public Indica che la risposta può (MAY) essere memorizzata da qualsiasi cache, anche se normalmente non sarebbe memorizzabile oppure sarebbe memorizzabile solo all'interno di una cache non condivisa. (Vedere anche Authorization, sezione 14.8, per ulteriori dettagli.)

private Indica che il messaggio di risposta, in tutto o in parte, è destinato a un singolo utente e non deve (MUST NOT) essere memorizzato da una cache condivisa. Ciò consente a un server di origine di dichiarare che le parti specificate della risposta sono destinate a un solo utente e non sono una risposta valida per le richieste di altri utenti. Una cache privata (non condivisa) può (MAY) memorizzare la risposta.

Nota: questo uso della parola private controlla soltanto il luogo in cui la risposta può essere memorizzata e non può garantire la riservatezza del contenuto del messaggio.

no-cache Se la direttiva no-cache non specifica un field-name, allora una cache non deve (MUST NOT) usare la risposta per soddisfare una richiesta successiva senza una rivalidazione riuscita con il server di origine. Ciò consente a un server di origine di impedire la memorizzazione in cache anche da parte di cache che sono state configurate per restituire risposte obsolete alle richieste dei client.

Se la direttiva no-cache specifica uno o più field-name, allora una cache può (MAY) usare la risposta per soddisfare una richiesta successiva, fatti salvi eventuali altri vincoli sulla memorizzazione in cache. Tuttavia, i field-name specificati non devono (MUST NOT) essere inviati nella risposta a una richiesta successiva senza una rivalidazione riuscita con il server di origine. Ciò consente a un server di origine di impedire il riutilizzo di determinati campi di intestazione in una risposta, pur continuando a consentire la memorizzazione in cache del resto della risposta.

Nota: la maggior parte delle cache HTTP/1.0 non riconoscerà né obbedirà a questa direttiva.

14.9.2 What May be Stored by Caches (Cosa Può essere Memorizzato dalle Cache)

no-store Lo scopo della direttiva no-store è impedire la divulgazione o la conservazione involontaria di informazioni sensibili (per esempio su nastri di backup). La direttiva no-store si applica all'intero messaggio e può (MAY) essere inviata sia in una risposta sia in una richiesta. Se inviata in una richiesta, una cache non deve (MUST NOT) memorizzare alcuna parte né di questa richiesta né di alcuna risposta a essa. Se inviata in una risposta, una cache non deve (MUST NOT) memorizzare alcuna parte né di questa risposta né della richiesta che l'ha provocata. Questa direttiva si applica sia alle cache non condivise sia a quelle condivise. "MUST NOT store" in questo contesto significa che la cache non deve (MUST NOT) memorizzare intenzionalmente le informazioni in una memoria non volatile e deve (MUST) compiere ogni sforzo ragionevole per rimuovere le informazioni dalla memoria volatile il più rapidamente possibile dopo averle inoltrate.

Anche quando questa direttiva è associata a una risposta, gli utenti potrebbero memorizzare esplicitamente tale risposta al di fuori del sistema di caching (per esempio con una finestra di dialogo "Salva con nome"). I buffer di cronologia possono (MAY) memorizzare tali risposte come parte del loro normale funzionamento.

Lo scopo di questa direttiva è soddisfare i requisiti dichiarati di taluni utenti e autori di servizi che sono preoccupati per le divulgazioni accidentali di informazioni attraverso accessi imprevisti alle strutture dati della cache. Sebbene l'uso di questa direttiva possa in alcuni casi migliorare la privacy, avvertiamo che non è (NOT) in alcun modo un meccanismo affidabile o sufficiente per garantire la privacy. In particolare, cache malevole o compromesse potrebbero non riconoscere né obbedire a questa direttiva, e le reti di comunicazione potrebbero essere vulnerabili all'intercettazione.

14.9.3 Modifications of the Basic Expiration Mechanism (Modifiche del Meccanismo di Scadenza di Base)

Il tempo di scadenza di un'entità può (MAY) essere specificato dal server di origine usando l'intestazione Expires (vedere la sezione 14.21). In alternativa, può (MAY) essere specificato usando la direttiva max-age in una risposta. Quando la direttiva di cache-control max-age è presente in una risposta memorizzata in cache, la risposta è obsoleta (stale) se la sua età corrente è maggiore del valore di età indicato (in secondi) al momento di una nuova richiesta per quella risorsa. La direttiva max-age su una risposta implica che la risposta è memorizzabile in cache (cioè "public"), a meno che non sia presente anche qualche altra direttiva di cache più restrittiva.

Se una risposta include sia un'intestazione Expires sia una direttiva max-age, la direttiva max-age prevale sull'intestazione Expires, anche se l'intestazione Expires è più restrittiva. Questa regola consente a un server di origine di fornire, per una data risposta, un tempo di scadenza più lungo a una cache HTTP/1.1 (o successiva) rispetto a una cache HTTP/1.0. Ciò può essere utile se determinate cache HTTP/1.0 calcolano in modo improprio le età o i tempi di scadenza, magari a causa di orologi desincronizzati.

Molte implementazioni di cache HTTP/1.0 tratteranno un valore Expires minore o uguale al valore Date della risposta come equivalente alla direttiva di risposta Cache-Control "no-cache". Se una cache HTTP/1.1 riceve una tale risposta e la risposta non include un campo di intestazione Cache-Control, dovrebbe (SHOULD) considerare la risposta non memorizzabile in cache, al fine di mantenere la compatibilità con i server HTTP/1.0.

Nota: un server di origine potrebbe voler utilizzare una funzionalità di controllo della cache HTTP relativamente recente, come la direttiva "private", su una rete che include cache più vecchie che non comprendono tale funzionalità. Il server di origine dovrà combinare la nuova funzionalità con un campo Expires il cui valore sia minore o uguale al valore Date. Ciò impedirà alle cache più vecchie di memorizzare in modo improprio la risposta.

s-maxage

Se una risposta include una direttiva s-maxage, allora per una cache condivisa (ma non per una cache privata) l'età massima specificata da questa direttiva prevale sull'età massima specificata dalla direttiva max-age o dall'intestazione Expires. La direttiva s-maxage implica anche la semantica della direttiva proxy-revalidate (vedere la sezione 14.9.4), cioè che la cache condivisa non deve usare la voce dopo che è diventata obsoleta per rispondere a una richiesta successiva senza prima averla rivalidata con il server di origine. La direttiva s-maxage viene sempre ignorata da una cache privata.

Si noti che la maggior parte delle cache più vecchie, non conformi a questa specifica, non implementa alcuna direttiva di cache-control. Un server di origine che desideri usare una direttiva di cache-control che limiti, ma non impedisca, la memorizzazione in cache da parte di una cache conforme a HTTP/1.1 può (MAY) sfruttare il requisito che la direttiva max-age prevale sull'intestazione Expires, nonché il fatto che le cache conformi a versioni precedenti a HTTP/1.1 non osservano la direttiva max-age.

Altre direttive consentono a uno user agent di modificare il meccanismo di scadenza di base. Queste direttive possono (MAY) essere specificate su una richiesta:

max-age

Indica che il client è disposto ad accettare una risposta la cui età non sia maggiore del tempo specificato in secondi. A meno che non sia inclusa anche la direttiva max-stale, il client non è disposto ad accettare una risposta obsoleta.

min-fresh

Indica che il client è disposto ad accettare una risposta la cui durata di freschezza non sia inferiore alla sua età corrente più il tempo specificato in secondi. Vale a dire, il client vuole una risposta che rimarrà fresca per almeno il numero di secondi specificato.

max-stale

Indica che il client è disposto ad accettare una risposta che ha superato il proprio tempo di scadenza. Se a max-stale è assegnato un valore, allora il client è disposto ad accettare una risposta che ha superato il proprio tempo di scadenza non più del numero di secondi specificato. Se a max-stale non è assegnato alcun valore, allora il client è disposto ad accettare una risposta obsoleta di qualsiasi età.

Se una cache restituisce una risposta obsoleta, sia a causa di una direttiva max-stale su una richiesta, sia perché la cache è configurata per sovrascrivere il tempo di scadenza di una risposta, la cache deve (MUST) allegare alla risposta obsoleta un'intestazione Warning, usando Warning 110 (Response is stale).

Una cache può (MAY) essere configurata per restituire risposte obsolete senza validazione, ma solo se ciò non è in conflitto con alcun requisito di livello "MUST" riguardante la validazione della cache (per esempio una direttiva di cache-control "must-revalidate").

Se sia la nuova richiesta sia la voce memorizzata in cache includono direttive "max-age", allora per determinare la freschezza della voce memorizzata in cache per quella richiesta si usa il minore dei due valori.

14.9.4 Cache Revalidation and Reload Controls (Controlli di Rivalidazione e Ricaricamento della Cache)

Talvolta uno user agent potrebbe volere o dover insistere affinché una cache rivalidi la propria voce di cache con il server di origine (e non soltanto con la cache successiva lungo il percorso verso il server di origine), oppure ricarichi la propria voce di cache dal server di origine. La rivalidazione end-to-end potrebbe essere necessaria se la cache o il server di origine ha sovrastimato il tempo di scadenza della risposta memorizzata in cache. Il ricaricamento end-to-end può essere necessario se la voce di cache si è corrotta per qualche motivo.

La rivalidazione end-to-end può essere richiesta sia quando il client non possiede una propria copia locale memorizzata in cache, nel qual caso la chiamiamo "rivalidazione end-to-end non specificata" (unspecified end-to-end revalidation), sia quando il client possiede effettivamente una copia locale memorizzata in cache, nel qual caso la chiamiamo "rivalidazione end-to-end specifica" (specific end-to-end revalidation).

Il client può specificare questi tre tipi di azione usando le direttive di richiesta Cache-Control:

Ricaricamento end-to-end (End-to-end reload)

La richiesta include una direttiva di cache-control "no-cache" oppure, per compatibilità con i client HTTP/1.0, "Pragma: no-cache". I nomi di campo non devono (MUST NOT) essere inclusi con la direttiva no-cache in una richiesta. Il server non deve (MUST NOT) usare una copia memorizzata in cache quando risponde a una tale richiesta.

Rivalidazione end-to-end specifica (Specific end-to-end revalidation)

La richiesta include una direttiva di cache-control "max-age=0", che forza ogni cache lungo il percorso verso il server di origine a rivalidare la propria voce, se presente, con la cache o il server successivi. La richiesta iniziale include un condizionale di validazione della cache con il validatore corrente del client.

Rivalidazione end-to-end non specificata (Unspecified end-to-end revalidation)

La richiesta include la direttiva di cache-control "max-age=0", che forza ogni cache lungo il percorso verso il server di origine a rivalidare la propria voce, se presente, con la cache o il server successivi. La richiesta iniziale non include un condizionale di validazione della cache; la prima cache lungo il percorso (se presente) che detiene una voce di cache per questa risorsa include un condizionale di validazione della cache con il proprio validatore corrente.

max-age

Quando una cache intermedia è forzata, per mezzo di una direttiva max-age=0, a rivalidare la propria voce di cache, e il client ha fornito il proprio validatore nella richiesta, il validatore fornito potrebbe differire dal validatore attualmente memorizzato con la voce di cache. In questo caso, la cache può (MAY) usare l'uno o l'altro validatore nel formulare la propria richiesta senza pregiudicare la trasparenza semantica.

Tuttavia, la scelta del validatore potrebbe influire sulle prestazioni. L'approccio migliore è che la cache intermedia usi il proprio validatore nel formulare la richiesta. Se il server risponde con 304 (Not Modified), allora la cache può restituire al client la propria copia ora validata con una risposta 200 (OK). Se invece il server risponde con una nuova entità e un nuovo validatore di cache, la cache intermedia può confrontare il validatore restituito con quello fornito nella richiesta del client, usando la funzione di confronto forte. Se il validatore del client è uguale a quello del server di origine, allora la cache intermedia restituisce semplicemente 304 (Not Modified). In caso contrario, restituisce la nuova entità con una risposta 200 (OK).

Se una richiesta include la direttiva no-cache, non dovrebbe (SHOULD NOT) includere min-fresh, max-stale o max-age.

only-if-cached

In alcuni casi, come in periodi di connettività di rete estremamente scarsa, un client può desiderare che una cache restituisca soltanto le risposte che essa ha attualmente memorizzato, e che non ricarichi né rivalidi con il server di origine. Per fare ciò, il client può includere la direttiva only-if-cached in una richiesta. Se riceve questa direttiva, una cache dovrebbe (SHOULD) rispondere o usando una voce memorizzata in cache che sia coerente con gli altri vincoli della richiesta, oppure con uno stato 504 (Gateway Timeout). Tuttavia, se un gruppo di cache è gestito come un sistema unificato con una buona connettività interna, una tale richiesta può (MAY) essere inoltrata all'interno di quel gruppo di cache.

must-revalidate

Poiché una cache può (MAY) essere configurata per ignorare il tempo di scadenza specificato da un server, e poiché una richiesta del client può (MAY) includere una direttiva max-stale (che ha un effetto simile), il protocollo include anche un meccanismo che consente al server di origine di esigere la rivalidazione di una voce di cache a ogni uso successivo. Quando la direttiva must-revalidate è presente in una risposta ricevuta da una cache, quella cache non deve (MUST NOT) usare la voce dopo che è diventata obsoleta per rispondere a una richiesta successiva senza prima averla rivalidata con il server di origine. (Cioè, la cache deve (MUST) eseguire ogni volta una rivalidazione end-to-end se, in base unicamente al valore Expires o max-age del server di origine, la risposta memorizzata in cache è obsoleta.)

La direttiva must-revalidate è necessaria per supportare il funzionamento affidabile di determinate funzionalità del protocollo. In ogni circostanza una cache HTTP/1.1 deve (MUST) obbedire alla direttiva must-revalidate; in particolare, se la cache non riesce a raggiungere il server di origine per qualsiasi motivo, deve (MUST) generare una risposta 504 (Gateway Timeout).

I server dovrebbero (SHOULD) inviare la direttiva must-revalidate se e solo se il mancato ricaricamento di una richiesta sull'entità potrebbe comportare un funzionamento scorretto, come una transazione finanziaria eseguita silenziosamente in modo difforme. I destinatari non devono (MUST NOT) intraprendere alcuna azione automatica che violi questa direttiva e non devono (MUST NOT) fornire automaticamente una copia non validata dell'entità se la rivalidazione fallisce.

Sebbene ciò non sia raccomandato, gli user agent che operano in condizioni di gravi limitazioni di connettività possono (MAY) violare questa direttiva ma, in tal caso, devono (MUST) avvisare esplicitamente l'utente che è stata fornita una risposta non validata. L'avviso deve (MUST) essere fornito a ogni accesso non validato e dovrebbe (SHOULD) richiedere una conferma esplicita dell'utente.

proxy-revalidate

La direttiva proxy-revalidate ha lo stesso significato della direttiva must-revalidate, tranne per il fatto che non si applica alle cache non condivise degli user agent. Può essere usata su una risposta a una richiesta autenticata per consentire alla cache dell'utente di memorizzare e successivamente restituire la risposta senza doverla rivalidare (poiché è già stata autenticata una volta da quell'utente), richiedendo comunque ai proxy che servono molti utenti di rivalidare ogni volta (per assicurarsi che ogni utente sia stato autenticato). Si noti che tali risposte autenticate necessitano anche della direttiva di controllo della cache public per poter essere memorizzate in cache.

14.9.5 No-Transform Directive (Direttiva No-Transform)

no-transform

Gli implementatori delle cache intermedie (proxy) hanno trovato utile convertire il tipo di media di determinati corpi di entità. Un proxy non trasparente potrebbe, per esempio, convertire tra formati di immagine al fine di risparmiare spazio nella cache o di ridurre la quantità di traffico su un collegamento lento.

Si verificano però gravi problemi operativi quando queste trasformazioni vengono applicate a corpi di entità destinati a certi tipi di applicazioni. Per esempio, le applicazioni per l'imaging medico, per l'analisi di dati scientifici e quelle che usano l'autenticazione end-to-end dipendono tutte dal ricevere un corpo di entità identico bit per bit all'entità-body originale.

Pertanto, se un messaggio include la direttiva no-transform, una cache intermedia o un proxy non deve (MUST NOT) modificare quelle intestazioni elencate nella sezione 13.5.2 come soggette alla direttiva no-transform. Ciò implica che la cache o il proxy non deve (MUST NOT) modificare alcun aspetto dell'entità-body specificato da queste intestazioni, compreso il valore dell'entità-body stesso.

14.9.6 Cache Control Extensions (Estensioni del Controllo della Cache)

Il campo di intestazione Cache-Control può essere esteso mediante l'uso di uno o più token di cache-extension, ciascuno con un valore assegnato opzionale. Le estensioni informative (quelle che non richiedono un cambiamento nel comportamento della cache) possono (MAY) essere aggiunte senza cambiare la semantica delle altre direttive. Le estensioni comportamentali sono progettate per funzionare come modificatori della base esistente di direttive di cache. Vengono fornite sia la nuova direttiva sia la direttiva standard, in modo tale che le applicazioni che non comprendono la nuova direttiva adottino per impostazione predefinita il comportamento specificato dalla direttiva standard, e quelle che comprendono la nuova direttiva la riconoscano come modificatrice dei requisiti associati alla direttiva standard. In questo modo è possibile estendere le direttive di cache-control senza richiedere modifiche al protocollo di base.

Questo meccanismo di estensione dipende dal fatto che una cache HTTP obbedisca a tutte le direttive di cache-control definite per la propria versione nativa di HTTP, obbedisca a determinate estensioni e ignori tutte le direttive che non comprende.

Per esempio, si consideri una ipotetica nuova direttiva di risposta chiamata community che agisce come modificatore della direttiva private. Definiamo questa nuova direttiva nel senso che, oltre a qualsiasi cache non condivisa, può memorizzare la risposta anche qualsiasi cache condivisa soltanto dai membri della community indicata nel suo valore. Un server di origine che desideri consentire alla community UCI di usare una risposta altrimenti privata nella o nelle loro cache condivise potrebbe farlo includendo

       Cache-Control: private, community="UCI"

Una cache che vede questo campo di intestazione agirà correttamente anche se non comprende la cache-extension community, poiché vedrà e comprenderà anche la direttiva private e quindi adotterà per impostazione predefinita il comportamento sicuro.

Le cache-directive non riconosciute devono (MUST) essere ignorate; si presume che qualsiasi cache-directive che probabilmente non sarà riconosciuta da una cache HTTP/1.1 venga combinata con direttive standard (o con la cacheability predefinita della risposta) in modo tale che il comportamento della cache rimanga minimamente corretto anche se la cache non comprende le estensioni.

14.10 Connection

Il campo di intestazione generale Connection consente al mittente di specificare le opzioni desiderate per quella particolare connessione e non deve (MUST NOT) essere comunicato dai proxy su connessioni ulteriori.

L'intestazione Connection ha la seguente grammatica:

       Connection = "Connection" ":" 1#(connection-token)
       connection-token  = token

I proxy HTTP/1.1 devono (MUST) analizzare il campo di intestazione Connection prima che un messaggio venga inoltrato e, per ogni connection-token in questo campo, rimuovere dal messaggio qualsiasi campo di intestazione che abbia lo stesso nome del connection-token. Le opzioni di connessione sono segnalate dalla presenza di un connection-token nel campo di intestazione Connection, e non da eventuali campi di intestazione aggiuntivi corrispondenti, poiché il campo di intestazione aggiuntivo potrebbe non essere inviato se non vi sono parametri associati a quell'opzione di connessione.

I campi di intestazione del messaggio elencati nell'intestazione Connection non devono (MUST NOT) includere intestazioni end-to-end, come Cache-Control.

HTTP/1.1 definisce l'opzione di connessione "close" affinché il mittente segnali che la connessione verrà chiusa dopo il completamento della risposta. Per esempio,

       Connection: close

nei campi di intestazione della richiesta o della risposta indica che la connessione non dovrebbe (SHOULD NOT) essere considerata persistent (sezione 8.1) dopo il completamento della richiesta/risposta corrente.

Le applicazioni HTTP/1.1 che non supportano le connessioni persistenti devono (MUST) includere l'opzione di connessione "close" in ogni messaggio.

Un sistema che riceve un messaggio HTTP/1.0 (o di versione inferiore) che include un'intestazione Connection deve (MUST), per ogni connection-token in questo campo, rimuovere e ignorare qualsiasi campo di intestazione del messaggio che abbia lo stesso nome del connection-token. Ciò protegge dall'inoltro erroneo di tali campi di intestazione da parte di proxy precedenti a HTTP/1.1. Vedere la sezione 19.6.2.

14.11 Content-Encoding

Il campo di intestazione di entità Content-Encoding viene usato come modificatore del tipo di media (media-type). Quando è presente, il suo valore indica quali ulteriori codifiche del contenuto sono state applicate all'entità-body, e quindi quali meccanismi di decodifica devono essere applicati per ottenere il tipo di media a cui fa riferimento il campo di intestazione Content-Type. Content-Encoding è usato principalmente per consentire di comprimere un documento senza perdere l'identità del suo tipo di media sottostante.

       Content-Encoding  = "Content-Encoding" ":" 1#content-coding

Le codifiche del contenuto sono definite nella sezione 3.5. Un esempio del suo uso è

       Content-Encoding: gzip

La content-coding è una caratteristica dell'entità identificata dalla Request-URI. Tipicamente, l'entità-body è memorizzata con questa codifica e viene decodificata soltanto prima del rendering o di un uso analogo. Tuttavia, un proxy non trasparente può (MAY) modificare la content-coding se la nuova codifica è nota come accettabile per il destinatario, a meno che nel messaggio non sia presente la direttiva di cache-control "no-transform".

Se la content-coding di un'entità non è "identity", allora la risposta deve (MUST) includere un'intestazione di entità Content-Encoding (sezione 14.11) che elenchi la o le content-coding non-identity usate.

Se la content-coding di un'entità in un messaggio di richiesta non è accettabile per il server di origine, il server dovrebbe (SHOULD) rispondere con un codice di stato 415 (Unsupported Media Type).

Se a un'entità sono state applicate più codifiche, le content-coding devono (MUST) essere elencate nell'ordine in cui sono state applicate. Informazioni aggiuntive sui parametri di codifica possono (MAY) essere fornite da altri campi di intestazione di entità non definiti da questa specifica.

14.12 Content-Language

Il campo di intestazione di entità Content-Language descrive la o le lingue naturali del pubblico a cui è destinata l'entità racchiusa. Si noti che ciò potrebbe non essere equivalente a tutte le lingue usate all'interno dell'entità-body.

       Content-Language  = "Content-Language" ":" 1#language-tag

I tag di lingua sono definiti nella sezione 3.10. Lo scopo principale di Content-Language è consentire a un utente di identificare e differenziare le entità in base alla propria lingua preferita. Pertanto, se il contenuto del corpo è destinato soltanto a un pubblico che legge il danese, il campo appropriato è

       Content-Language: da

Se non viene specificato alcun Content-Language, il valore predefinito è che il contenuto è destinato a pubblici di tutte le lingue. Ciò potrebbe significare che il mittente non lo considera specifico di alcuna lingua naturale, oppure che il mittente non sa a quale lingua è destinato.

Possono (MAY) essere elencate più lingue per contenuti destinati a più pubblici. Per esempio, una versione del "Trattato di Waitangi", presentata simultaneamente nella stesura originale in māori e in inglese, richiederebbe

       Content-Language: mi, en

Tuttavia, il semplice fatto che in un'entità siano presenti più lingue non significa che essa sia destinata a più pubblici linguistici. Un esempio sarebbe un manuale di lingua per principianti, come "A First Lesson in Latin", che è chiaramente destinato a essere usato da un pubblico che legge l'inglese. In questo caso, il Content-Language includerebbe propriamente soltanto "en".

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

14.13 Content-Length

Il campo di intestazione di entità Content-Length indica la dimensione dell'entità-body, in numero decimale di OCTET, inviata al destinatario oppure, nel caso del metodo HEAD, la dimensione dell'entità-body che sarebbe stata inviata se la richiesta fosse stata una GET.

       Content-Length    = "Content-Length" ":" 1*DIGIT

Un esempio è

       Content-Length: 3495

Le applicazioni dovrebbero (SHOULD) usare questo campo per indicare la transfer-length del message-body, a meno che ciò non sia vietato dalle regole della sezione 4.4.

Qualsiasi Content-Length maggiore o uguale a zero è un valore valido. La sezione 4.4 descrive come determinare la lunghezza di un message-body se non viene fornito alcun Content-Length.

Si noti che il significato di questo campo è significativamente diverso dalla corrispondente definizione in MIME, dove è un campo opzionale usato all'interno del content-type "message/external-body". In HTTP, dovrebbe (SHOULD) essere inviato ogni volta che la lunghezza del messaggio può essere determinata prima della trasmissione, a meno che ciò non sia vietato dalle regole della sezione 4.4.

14.14 Content-Location

Il campo di intestazione di entità Content-Location può (MAY) essere usato per fornire la posizione della risorsa per l'entità racchiusa nel messaggio, quando tale entità è accessibile da una posizione diversa dalla URI della risorsa richiesta. Un server dovrebbe (SHOULD) fornire un Content-Location per la variante corrispondente all'entità della risposta; specialmente nel caso in cui una risorsa abbia più entità associate e tali entità abbiano effettivamente posizioni separate dalle quali possono essere accessibili singolarmente, il server dovrebbe (SHOULD) fornire un Content-Location per la particolare variante restituita.

       Content-Location = "Content-Location" ":"
                         ( absoluteURI | relativeURI )

Il valore di Content-Location definisce anche la base URI per l'entità.

Il valore di Content-Location non sostituisce la URI originale richiesta; è soltanto una dichiarazione della posizione della risorsa corrispondente a questa particolare entità al momento della richiesta. Richieste future possono (MAY) specificare la URI di Content-Location come request-URI se il desiderio è identificare l'origine di quella particolare entità.

Una cache non può presumere che un'entità con un Content-Location diverso dalla URI usata per recuperarla possa essere usata per rispondere a richieste successive su quella URI di Content-Location. Tuttavia, il Content-Location può essere usato per differenziare più entità recuperate da un'unica risorsa richiesta, come descritto nella sezione 13.6.

Se il Content-Location è una URI relativa, la URI relativa è interpretata rispetto alla Request-URI.

Il significato dell'intestazione Content-Location nelle richieste PUT o POST non è definito; in tali casi i server sono liberi di ignorarla.

14.15 Content-MD5

Il campo di intestazione di entità Content-MD5, come definito in RFC 1864 [23], è un digest MD5 dell'entità-body allo scopo di fornire un controllo di integrità del messaggio (MIC, message integrity check) end-to-end dell'entità-body. (Nota: un MIC è utile per rilevare modifiche accidentali dell'entità-body durante il transito, ma non costituisce una prova contro attacchi malevoli.)

        Content-MD5   = "Content-MD5" ":" md5-digest
        md5-digest   = `<base64 of 128 bit MD5 digest as per RFC 1864>`

Il campo di intestazione Content-MD5 può (MAY) essere generato da un server di origine o da un client per funzionare come controllo di integrità dell'entità-body. Soltanto i server di origine o i client possono (MAY) generare il campo di intestazione Content-MD5; i proxy e i gateway non devono (MUST NOT) generarlo, poiché ciò ne vanificherebbe il valore come controllo di integrità end-to-end. Qualsiasi destinatario dell'entità-body, compresi gateway e proxy, può (MAY) verificare che il valore del digest in questo campo di intestazione corrisponda a quello dell'entità-body ricevuta.

Il digest MD5 è calcolato in base al contenuto dell'entità-body, includendo qualsiasi content-coding applicata, ma non includendo alcuna transfer-encoding applicata al message-body. Se il messaggio viene ricevuto con una transfer-encoding, tale codifica deve (MUST) essere rimossa prima di verificare il valore di Content-MD5 rispetto all'entità ricevuta.

Ne consegue che il digest è calcolato sugli ottetti dell'entità-body esattamente come, e nell'ordine in cui, sarebbero stati inviati se non fosse stata applicata alcuna transfer-encoding.

HTTP estende RFC 1864 per consentire di calcolare il digest anche per i tipi di media compositi MIME (per esempio multipart/* e message/rfc822), ma ciò non cambia il modo in cui il digest è calcolato, come definito nel paragrafo precedente.

Da ciò derivano diverse conseguenze. L'entità-body dei tipi compositi può (MAY) contenere molte body-part, ciascuna con le proprie intestazioni MIME e HTTP (comprese le intestazioni Content-MD5, Content-Transfer-Encoding e Content-Encoding). Se una body-part ha un'intestazione Content-Transfer-Encoding o Content-Encoding, si presume che al contenuto della body-part sia stata applicata la codifica, e la body-part è inclusa nel digest Content-MD5 così com'è, cioè dopo l'applicazione. Il campo di intestazione Transfer-Encoding non è ammesso all'interno delle body-part.

La conversione di tutte le interruzioni di riga in CRLF non deve (MUST NOT) essere effettuata prima di calcolare o verificare il digest: la convenzione di interruzione di riga usata nel testo effettivamente trasmesso deve (MUST) essere lasciata inalterata durante il calcolo del digest.

Nota: sebbene la definizione di Content-MD5 sia esattamente la stessa per HTTP e per le entità-body MIME in RFC 1864, vi sono diversi modi in cui l'applicazione di Content-MD5 alle entità-body HTTP differisce dalla sua applicazione alle entità-body MIME. Uno è che HTTP, a differenza di MIME, non usa Content-Transfer-Encoding, mentre usa Transfer-Encoding e Content-Encoding. Un altro è che HTTP usa tipi di contenuto binari più di frequente rispetto a MIME, quindi vale la pena osservare che, in tali casi, l'ordine dei byte usato per calcolare il digest è l'ordine dei byte di trasmissione definito per il tipo. Infine, HTTP consente la trasmissione di tipi testuali con diverse convenzioni di interruzione di riga e non solo la forma canonica che usa CRLF.

14.16 Content-Range

L'intestazione di entità Content-Range viene inviata con un'entità-body parziale per specificare dove, nell'entità-body completa, debba essere applicato il corpo parziale. Le unità di intervallo sono definite nella sezione 3.12.

       Content-Range = "Content-Range" ":" content-range-spec

       content-range-spec      = byte-content-range-spec
       byte-content-range-spec = bytes-unit SP
                                 byte-range-resp-spec "/"
                                 ( instance-length | "*" )

       byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
                                      | "*"
       instance-length           = 1*DIGIT

L'intestazione dovrebbe (SHOULD) indicare la lunghezza totale dell'entità-body completa, a meno che tale lunghezza sia sconosciuta o difficile da determinare. Il carattere asterisco "*" significa che l'instance-length è sconosciuta al momento in cui la risposta è stata generata.

A differenza dei valori byte-ranges-specifier (vedere la sezione 14.35.1), un byte-range-resp-spec deve (MUST) specificare un solo intervallo e deve (MUST) contenere posizioni di byte assolute sia per il primo sia per l'ultimo byte dell'intervallo.

Un byte-content-range-spec il cui byte-range-resp-spec abbia un valore last-byte-pos minore del suo valore first-byte-pos, oppure il cui valore instance-length sia minore o uguale al suo valore last-byte-pos, non è valido. Il destinatario di un byte-content-range-spec non valido deve (MUST) ignorarlo, insieme a qualsiasi contenuto trasmesso con esso.

Un server che invia una risposta con codice di stato 416 (Requested range not satisfiable) dovrebbe (SHOULD) includere un campo Content-Range con un byte-range-resp-spec pari a "". L'instance-length specifica la lunghezza corrente della risorsa selezionata. Una risposta con codice di stato 206 (Partial Content) non deve (MUST NOT) includere un campo Content-Range con un byte-range-resp-spec pari a "".

Esempi di valori byte-content-range-spec, supponendo che l'entità contenga complessivamente 1234 byte:

      . The first 500 bytes:
       bytes 0-499/1234

      . The second 500 bytes:
       bytes 500-999/1234

      . All except for the first 500 bytes:
       bytes 500-1233/1234

      . The last 500 bytes:
       bytes 734-1233/1234

Quando un messaggio HTTP include il contenuto di un singolo intervallo (per esempio la risposta a una richiesta di un singolo intervallo, o a una richiesta di un insieme di intervalli che si sovrappongono senza lacune), questo contenuto viene trasmesso con un'intestazione Content-Range e un'intestazione Content-Length che mostra il numero di byte effettivamente trasferiti. Per esempio,

       HTTP/1.1 206 Partial content
       Date: Wed, 15 Nov 1995 06:25:24 GMT
       Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
       Content-Range: bytes 21010-47021/47022
       Content-Length: 26012
       Content-Type: image/gif

Quando un messaggio HTTP include il contenuto di più intervalli (per esempio la risposta a una richiesta di più intervalli non sovrapposti), questi vengono trasmessi come messaggio multipart. Il tipo di media multipart usato a questo scopo è "multipart/byteranges", come definito nell'appendice 19.2. Per un problema di compatibilità, vedere l'appendice 19.6.3.

Una risposta a una richiesta di un singolo intervallo non deve (MUST NOT) essere inviata usando il tipo di media multipart/byteranges. Una risposta a una richiesta di più intervalli, il cui risultato è un singolo intervallo, può (MAY) essere inviata come tipo di media multipart/byteranges con una sola parte. Un client che non è in grado di decodificare un messaggio multipart/byteranges non deve (MUST NOT) chiedere più intervalli di byte in una singola richiesta.

Quando un client richiede più intervalli di byte in una sola richiesta, il server dovrebbe (SHOULD) restituirli nell'ordine in cui sono apparsi nella richiesta.

Se il server ignora un byte-range-spec perché sintatticamente non valido, il server dovrebbe (SHOULD) trattare la richiesta come se il campo di intestazione Range non valido non esistesse. (Normalmente questo significa restituire una risposta 200 contenente l'entità completa.)

Se il server riceve una richiesta (diversa da una che include un campo di intestazione di richiesta If-Range) con un campo di intestazione di richiesta Range non soddisfacibile (cioè tale che tutti i valori byte-range-spec abbiano un valore first-byte-pos maggiore della lunghezza corrente della risorsa selezionata), dovrebbe (SHOULD) restituire un codice di risposta 416 (Requested range not satisfiable) (sezione 10.4.17).

Nota: i client non possono dipendere dal fatto che i server inviino una risposta 416 (Requested range not satisfiable) invece di una risposta 200 (OK) per una richiesta di intervallo non soddisfacibile, poiché non tutti i server implementano questo campo di intestazione di richiesta.

14.17 Content-Type

Il campo di intestazione di entità Content-Type indica il tipo di media dell'entità-body inviata al destinatario oppure, nel caso del metodo HEAD, il tipo di media che sarebbe stato inviato se la richiesta fosse stata una GET.

       Content-Type   = "Content-Type" ":" media-type

I tipi di media sono definiti nella sezione 3.7. Un esempio del campo è

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

Un'ulteriore trattazione dei metodi per identificare il tipo di media di un'entità è fornita nella sezione 7.2.1.

14.18 Date

Il campo di intestazione generale Date rappresenta la data e l'ora in cui il messaggio è stato originato, con la stessa semantica di orig-date in RFC 822. Il valore del campo è una HTTP-date, come descritto nella sezione 3.3.1; deve (MUST) essere inviato nel formato data di RFC 1123 [8].

       Date  = "Date" ":" HTTP-date

Un esempio è

       Date: Tue, 15 Nov 1994 08:12:31 GMT

I server di origine devono (MUST) includere un campo di intestazione Date in tutte le risposte, tranne nei seguenti casi:

1. Se il codice di stato della risposta è 100 (Continue) o 101 (Switching Protocols), la risposta può (MAY) includere un campo di intestazione Date, a scelta del server.

2. Se il codice di stato della risposta indica un errore del server, per esempio 500 (Internal Server Error) o 503 (Service Unavailable), ed è scomodo o impossibile generare una Date valida.

3. Se il server non dispone di un orologio in grado di fornire un'approssimazione ragionevole dell'ora corrente, le sue risposte non devono (MUST NOT) includere un campo di intestazione Date. In questo caso devono (MUST) essere seguite le regole della sezione 14.18.1.

A un messaggio ricevuto che non ha un campo di intestazione Date deve (MUST) esserne assegnato uno dal destinatario, se il messaggio sarà memorizzato in cache da quel destinatario o passerà attraverso un gateway tramite un protocollo che richiede una Date. Un'implementazione HTTP priva di orologio non deve (MUST NOT) memorizzare in cache le risposte senza rivalidarle a ogni uso. Una cache HTTP, specialmente una cache condivisa, dovrebbe (SHOULD) usare un meccanismo, come NTP [28], per sincronizzare il proprio orologio con uno standard esterno affidabile.

I client dovrebbero (SHOULD) inviare un campo di intestazione Date soltanto in messaggi che includono un'entità-body, come nel caso delle richieste PUT e POST, e anche in tal caso è facoltativo. Un client privo di orologio non deve (MUST NOT) inviare un campo di intestazione Date in una richiesta.

La HTTP-date inviata in un'intestazione Date non dovrebbe (SHOULD NOT) rappresentare una data e un'ora successive alla generazione del messaggio. Dovrebbe (SHOULD) rappresentare la migliore approssimazione disponibile della data e dell'ora di generazione del messaggio, a meno che l'implementazione non abbia alcun mezzo per generare una data e un'ora ragionevolmente accurate. In teoria, la data dovrebbe rappresentare il momento immediatamente precedente alla generazione dell'entità. In pratica, la data può essere generata in qualsiasi momento durante l'origine del messaggio senza che ciò ne pregiudichi il valore semantico.

14.18.1 Clockless Origin Server Operation (Funzionamento del Server di Origine senza Orologio)

Alcune implementazioni di server di origine potrebbero non disporre di un orologio. Un server di origine privo di orologio non deve (MUST NOT) assegnare valori Expires o Last-Modified a una risposta, a meno che tali valori non siano stati associati alla risorsa da un sistema o da un utente dotato di un orologio affidabile. Può (MAY) assegnare un valore Expires che sia noto, al momento o prima della configurazione del server, come collocato nel passato (ciò consente la "pre-scadenza" delle risposte senza memorizzare valori Expires distinti per ogni risorsa).

14.19 ETag

Il campo di intestazione di risposta ETag fornisce il valore corrente dell'entity tag per la variante richiesta. Le intestazioni usate con gli entity tag sono descritte nelle sezioni 14.24, 14.26 e 14.44. L'entity tag può (MAY) essere usato per il confronto con altre entità della stessa risorsa (vedere la sezione 13.3.3).

      ETag = "ETag" ":" entity-tag

Esempi:

      ETag: "xyzzy"
      ETag: W/"xyzzy"
      ETag: ""

14.20 Expect

Il campo di intestazione di richiesta Expect viene usato per indicare che particolari comportamenti del server sono richiesti dal client.

      Expect       =  "Expect" ":" 1#expectation

      expectation  =  "100-continue" | expectation-extension
      expectation-extension =  token [ "=" ( token | quoted-string )
                               *expect-params ]
      expect-params =  ";" token [ "=" ( token | quoted-string ) ]

Un server che non comprende o non è in grado di conformarsi a uno qualsiasi dei valori di expectation nel campo Expect di una richiesta deve (MUST) rispondere con un opportuno stato di errore. Il server deve (MUST) rispondere con uno stato 417 (Expectation Failed) se una qualsiasi delle expectation non può essere soddisfatta o, se vi sono altri problemi con la richiesta, con qualche altro stato 4xx.

Questo campo di intestazione è definito con una sintassi estensibile per consentire estensioni future. Se un server riceve una richiesta contenente un campo Expect che include una expectation-extension che non supporta, deve (MUST) rispondere con uno stato 417 (Expectation Failed).

Il confronto dei valori di expectation non distingue tra maiuscole e minuscole per i token non racchiusi tra virgolette (compreso il token 100-continue), mentre distingue tra maiuscole e minuscole per le expectation-extension espresse come quoted-string.

Il meccanismo Expect è hop-by-hop: vale a dire che un proxy HTTP/1.1 deve (MUST) restituire uno stato 417 (Expectation Failed) se riceve una richiesta con una expectation che non è in grado di soddisfare. Tuttavia, l'intestazione di richiesta Expect stessa è end-to-end; deve (MUST) essere inoltrata se la richiesta viene inoltrata.

Molte applicazioni HTTP/1.0 e HTTP/1.1 più vecchie non comprendono l'intestazione Expect.

Per l'uso dello stato 100 (continue), vedere la sezione 8.2.3.

14.21 Expires

Il campo di intestazione di entità Expires indica la data/ora dopo la quale la risposta è considerata obsoleta. Una voce di cache obsoleta normalmente non può essere restituita da una cache (sia essa una cache proxy o una cache di user agent) a meno che non venga prima validata con il server di origine (o con una cache intermedia che possiede una copia fresca dell'entità). Per un'ulteriore trattazione del modello di scadenza, vedere la sezione 13.2.

La presenza di un campo Expires non implica che la risorsa originale cambierà o cesserà di esistere in quel momento, prima o dopo di esso.

Il formato è una data e un'ora assolute come definite dalla HTTP-date nella sezione 3.3.1; deve (MUST) essere nel formato data di RFC 1123:

      Expires = "Expires" ":" HTTP-date

Un esempio del suo uso è

      Expires: Thu, 01 Dec 1994 16:00:00 GMT

Nota: se una risposta include un campo Cache-Control con la direttiva max-age (vedere la sezione 14.9.3), quella direttiva prevale sul campo Expires.

I client e le cache HTTP/1.1 devono (MUST) trattare gli altri formati di data non validi, in particolare il valore "0", come collocati nel passato (cioè "già scaduti").

Per contrassegnare una risposta come "già scaduta", un server di origine invia una data Expires uguale al valore dell'intestazione Date. (Vedere le regole per i calcoli di scadenza nella sezione 13.2.4.)

Per contrassegnare una risposta come "che non scade mai", un server di origine invia una data Expires approssimativamente a un anno di distanza dal momento in cui la risposta viene inviata. I server HTTP/1.1 non dovrebbero (SHOULD NOT) inviare date Expires che vadano oltre un anno nel futuro.

La presenza di un campo di intestazione Expires con un valore di data collocato nel futuro su una risposta che altrimenti sarebbe per impostazione predefinita non memorizzabile in cache indica che la risposta è memorizzabile in cache, a meno che non sia indicato diversamente da un campo di intestazione Cache-Control (sezione 14.9).

14.22 From

Il campo di intestazione di richiesta From, se fornito, dovrebbe (SHOULD) contenere un indirizzo di posta elettronica Internet dell'utente umano che controlla lo user agent richiedente. L'indirizzo dovrebbe (SHOULD) essere utilizzabile dalla macchina, come definito da "mailbox" in RFC 822 [9] come aggiornato da RFC 1123 [8]:

       From   = "From" ":" mailbox

Un esempio è:

       From: [email protected]

Questo campo di intestazione può (MAY) essere usato per finalità di registrazione (logging) e come mezzo per identificare l'origine di richieste non valide o indesiderate. Non dovrebbe (SHOULD NOT) essere usato come forma insicura di protezione dell'accesso. L'interpretazione di questo campo è che la richiesta viene effettuata per conto della persona indicata, la quale si assume la responsabilità del metodo eseguito. In particolare, gli agenti robot dovrebbero (SHOULD) includere questa intestazione, così che la persona responsabile dell'esecuzione del robot possa essere contattata se si verificano problemi sul lato ricevente.

L'indirizzo di posta elettronica Internet in questo campo può (MAY) essere diverso dall'host Internet che ha emesso la richiesta. Per esempio, quando una richiesta passa attraverso un proxy, dovrebbe (SHOULD) essere usato l'indirizzo dell'emittente originale.

Il client non dovrebbe (SHOULD NOT) inviare il campo di intestazione From senza l'approvazione dell'utente, poiché ciò potrebbe entrare in conflitto con gli interessi dell'utente in materia di privacy o con la politica di sicurezza del suo sito. Si raccomanda vivamente che l'utente possa disabilitare, abilitare e modificare il valore di questo campo in qualsiasi momento prima di una richiesta.

14.23 Host

Il campo di intestazione di richiesta Host specifica l'host Internet e il numero di porta della risorsa richiesta, come ottenuti dalla URI originale fornita dall'utente o dalla risorsa di riferimento (generalmente un URL HTTP, come descritto nella sezione 3.2.2). Il valore del campo Host deve (MUST) rappresentare l'autorità di denominazione del server di origine o del gateway indicata dall'URL originale. Ciò consente al server di origine o al gateway di differenziare tra URL internamente ambigui, come l'URL radice "/" di un server per più nomi host su un unico indirizzo IP.

       Host = "Host" ":" host [ ":" port ] ; Section 3.2.2

Un "host" senza alcuna informazione di porta finale implica la porta predefinita per il servizio richiesto (per esempio "80" per un URL HTTP). Per esempio, una richiesta sul server di origine per http://www.w3.org/pub/WWW/ includerebbe propriamente:

       GET /pub/WWW/ HTTP/1.1
       Host: www.w3.org

Un client deve (MUST) includere un campo di intestazione Host in tutti i messaggi di richiesta HTTP/1.1. Se la URI richiesta non include un nome host Internet per il servizio richiesto, allora il campo di intestazione Host deve (MUST) essere fornito con un valore vuoto. Un proxy HTTP/1.1 deve (MUST) assicurarsi che qualsiasi messaggio di richiesta che inoltra contenga un campo di intestazione Host appropriato che identifichi il servizio richiesto dal proxy. Tutti i server HTTP/1.1 basati su Internet devono (MUST) rispondere con un codice di stato 400 (Bad Request) a qualsiasi messaggio di richiesta HTTP/1.1 privo di un campo di intestazione Host.

Per altri requisiti relativi a Host, vedere le sezioni 5.2 e 19.6.1.1.

14.24 If-Match

Il campo di intestazione di richiesta If-Match viene usato con un metodo per renderlo condizionale. Un client che ha in precedenza ottenuto una o più entità dalla risorsa può verificare che una di quelle entità sia corrente includendo un elenco dei loro entity tag associati nel campo di intestazione If-Match. Gli entity tag sono definiti nella sezione 3.11. Lo scopo di questa funzionalità è consentire aggiornamenti efficienti delle informazioni memorizzate in cache con un sovraccarico transazionale minimo. Essa viene anche usata, sulle richieste di aggiornamento, per prevenire la modifica involontaria della versione sbagliata di una risorsa. Come caso speciale, il valore "*" corrisponde a qualsiasi entità corrente della risorsa.

       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

Se uno qualsiasi degli entity tag corrisponde all'entity tag dell'entità che sarebbe stata restituita nella risposta a una richiesta GET simile (senza l'intestazione If-Match) su quella risorsa, oppure se viene fornito "*" ed esiste qualsiasi entità corrente per quella risorsa, allora il server può (MAY) eseguire il metodo richiesto come se il campo di intestazione If-Match non esistesse.

Un server deve (MUST) usare la funzione di confronto forte (vedere la sezione 13.3.3) per confrontare gli entity tag in If-Match.

Se nessuno degli entity tag corrisponde, oppure se viene fornito "*" e non esiste alcuna entità corrente, il server non deve (MUST NOT) eseguire il metodo richiesto e deve (MUST) restituire una risposta 412 (Precondition Failed). Questo comportamento è particolarmente utile quando il client vuole impedire che un metodo di aggiornamento, come PUT, modifichi una risorsa che è cambiata da quando il client l'ha recuperata l'ultima volta.

Se la richiesta, senza il campo di intestazione If-Match, darebbe come risultato qualcosa di diverso da uno stato 2xx o 412, allora l'intestazione If-Match deve (MUST) essere ignorata.

Il significato di "If-Match: *" è che il metodo dovrebbe (SHOULD) essere eseguito se esiste la rappresentazione selezionata dal server di origine (o da una cache, eventualmente usando il meccanismo Vary, vedere la sezione 14.44), e non deve (MUST NOT) essere eseguito se la rappresentazione non esiste.

Una richiesta intesa ad aggiornare una risorsa (per esempio una PUT) può (MAY) includere un campo di intestazione If-Match per segnalare che il metodo di richiesta non deve (MUST NOT) essere applicato se l'entità corrispondente al valore di If-Match (un singolo entity tag) non è più una rappresentazione di quella risorsa. Ciò consente all'utente di indicare di non desiderare che la richiesta vada a buon fine se la risorsa è stata modificata a sua insaputa. Esempi:

       If-Match: "xyzzy"
       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       If-Match: *

Il risultato di una richiesta che presenti sia un campo di intestazione If-Match sia un campo di intestazione If-None-Match o If-Modified-Since non è definito da questa specifica.

14.25 If-Modified-Since

Il campo di intestazione di richiesta If-Modified-Since viene usato con un metodo per renderlo condizionale: se la variante richiesta non è stata modificata dopo il tempo specificato in questo campo, dal server non verrà restituita alcuna entità; verrà invece restituita una risposta 304 (not modified) senza alcun message-body.

       If-Modified-Since = "If-Modified-Since" ":" HTTP-date

Un esempio del campo è:

       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Un metodo GET con un'intestazione If-Modified-Since e nessuna intestazione Range richiede che l'entità identificata sia trasferita soltanto se è stata modificata dopo la data indicata dall'intestazione If-Modified-Since. L'algoritmo per determinarlo comprende i seguenti casi:

a) Se la richiesta darebbe normalmente come risultato qualcosa di diverso da uno stato 200 (OK), oppure se la data If-Modified-Since fornita non è valida, la risposta è esattamente la stessa di una GET normale. Una data successiva all'ora corrente del server non è valida.

b) Se la variante è stata modificata dopo la data If-Modified-Since, la risposta è esattamente la stessa di una GET normale.

c) Se la variante non è stata modificata dopo una data If-Modified-Since valida, il server dovrebbe (SHOULD) restituire una risposta 304 (Not Modified).

Lo scopo di questa funzionalità è consentire aggiornamenti efficienti delle informazioni memorizzate in cache con un sovraccarico transazionale minimo.

Nota: il campo di intestazione di richiesta Range modifica il significato di If-Modified-Since; per tutti i dettagli, vedere la sezione 14.35.

Nota: i tempi di If-Modified-Since sono interpretati dal server, il cui orologio potrebbe non essere sincronizzato con quello del client.

Nota: nel gestire un campo di intestazione If-Modified-Since, alcuni server useranno una funzione di confronto esatto delle date, anziché una funzione di minore, per decidere se inviare una risposta 304 (Not Modified). Per ottenere i risultati migliori nell'inviare un campo di intestazione If-Modified-Since a fini di validazione della cache, si consiglia ai client di usare, quando possibile, la stringa di data esatta ricevuta in un precedente campo di intestazione Last-Modified.

Nota: se un client usa una data arbitraria nell'intestazione If-Modified-Since anziché una data presa dall'intestazione Last-Modified per la stessa richiesta, il client dovrebbe essere consapevole del fatto che questa data viene interpretata secondo la concezione del tempo del server. Il client dovrebbe considerare gli orologi non sincronizzati e i problemi di arrotondamento dovuti alle diverse codifiche del tempo tra client e server. Ciò comprende la possibilità di condizioni di gara se il documento è cambiato tra il momento in cui è stato richiesto la prima volta e la data If-Modified-Since di una richiesta successiva, nonché la possibilità di problemi legati allo scostamento degli orologi se la data If-Modified-Since deriva dall'orologio del client senza correzione rispetto all'orologio del server. Le correzioni per le diverse basi temporali tra client e server sono nella migliore delle ipotesi approssimative a causa della latenza della rete.

Il risultato di una richiesta che presenti sia un campo di intestazione If-Modified-Since sia un campo di intestazione If-Match o If-Unmodified-Since non è definito da questa specifica.

14.26 If-None-Match

Il campo di intestazione di richiesta If-None-Match viene usato con un metodo per renderlo condizionale. Un client che ha in precedenza ottenuto una o più entità dalla risorsa può verificare che nessuna di quelle entità sia corrente includendo un elenco dei loro entity tag associati nel campo di intestazione If-None-Match. Lo scopo di questa funzionalità è consentire aggiornamenti efficienti delle informazioni memorizzate in cache con un sovraccarico transazionale minimo. Essa viene anche usata per impedire che un metodo (per esempio PUT) modifichi inavvertitamente una risorsa esistente quando il client ritiene che la risorsa non esista.

Come caso speciale, il valore "*" corrisponde a qualsiasi entità corrente della risorsa.

       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

Se uno qualsiasi degli entity tag corrisponde all'entity tag dell'entità che sarebbe stata restituita nella risposta a una richiesta GET simile (senza l'intestazione If-None-Match) su quella risorsa, oppure se viene fornito "*" ed esiste qualsiasi entità corrente per quella risorsa, allora il server non deve (MUST NOT) eseguire il metodo richiesto, a meno che non sia tenuto a farlo perché la data di modifica della risorsa non corrisponde a quella fornita in un campo di intestazione If-Modified-Since nella richiesta. Al contrario, se il metodo di richiesta era GET o HEAD, il server dovrebbe (SHOULD) rispondere con una risposta 304 (Not Modified), includendo i campi di intestazione relativi alla cache (in particolare ETag) di una delle entità che corrispondevano. Per tutti gli altri metodi di richiesta, il server deve (MUST) rispondere con uno stato 412 (Precondition Failed).

Per le regole su come determinare se due entity tag corrispondono, vedere la sezione 13.3.3. La funzione di confronto debole può essere usata solo con richieste GET o HEAD.

Se nessuno degli entity tag corrisponde, allora il server può (MAY) eseguire il metodo richiesto come se il campo di intestazione If-None-Match non esistesse, ma deve (MUST) anche ignorare qualsiasi campo di intestazione If-Modified-Since presente nella richiesta. Vale a dire, se nessun entity tag corrisponde, allora il server non deve (MUST NOT) restituire una risposta 304 (Not Modified).

Se la richiesta, senza il campo di intestazione If-None-Match, darebbe come risultato qualcosa di diverso da uno stato 2xx o 304, allora l'intestazione If-None-Match deve (MUST) essere ignorata. (Per una discussione sul comportamento del server quando nella stessa richiesta compaiono sia If-Modified-Since sia If-None-Match, vedere la sezione 13.3.4.)

Il significato di "If-None-Match: *" è che il metodo non deve (MUST NOT) essere eseguito se esiste la rappresentazione selezionata dal server di origine (o da una cache, eventualmente usando il meccanismo Vary, vedere la sezione 14.44), e dovrebbe (SHOULD) essere eseguito se la rappresentazione non esiste. Questa funzionalità è intesa a essere utile per prevenire corse tra operazioni PUT.

Esempi:

       If-None-Match: "xyzzy"
       If-None-Match: W/"xyzzy"
       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
       If-None-Match: *

Il risultato di una richiesta che presenti sia un campo di intestazione If-None-Match sia un campo di intestazione If-Match o If-Unmodified-Since non è definito da questa specifica.

14.27 If-Range

Se un client ha una copia parziale di un'entità nella propria cache e desidera averne una copia aggiornata dell'entità completa, potrebbe usare l'intestazione di richiesta Range con una GET condizionale (usando If-Unmodified-Since e/o If-Match). Tuttavia, se la condizione fallisce perché l'entità è stata modificata, il client dovrebbe poi effettuare una seconda richiesta per ottenere l'intera entità-body corrente.

L'intestazione If-Range consente a un client di "cortocircuitare" la seconda richiesta. In termini informali, il suo significato è if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity.

        If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

Se il client non ha un entity tag per un'entità, ma ha una data Last-Modified, può (MAY) usare quella data in un'intestazione If-Range. (Il server può distinguere tra una HTTP-date valida e qualsiasi forma di entity-tag esaminando non più di due caratteri.) L'intestazione If-Range dovrebbe (SHOULD) essere usata solo insieme a un'intestazione Range e deve (MUST) essere ignorata se la richiesta non include un'intestazione Range, o se il server non supporta l'operazione su sottointervalli.

Se l'entity tag fornito nell'intestazione If-Range corrisponde all'entity tag corrente dell'entità, allora il server dovrebbe (SHOULD) fornire il sottointervallo specificato dell'entità usando una risposta 206 (Partial content). Se l'entity tag non corrisponde, allora il server dovrebbe (SHOULD) restituire l'intera entità usando una risposta 200 (OK).

14.28 If-Unmodified-Since

Il campo di intestazione di richiesta If-Unmodified-Since viene usato con un metodo per renderlo condizionale. Se la risorsa richiesta non è stata modificata dopo il tempo specificato in questo campo, il server dovrebbe (SHOULD) eseguire l'operazione richiesta come se l'intestazione If-Unmodified-Since non fosse presente.

Se la variante richiesta è stata modificata dopo il tempo specificato, il server non deve (MUST NOT) eseguire l'operazione richiesta e deve (MUST) restituire un 412 (Precondition Failed).

      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

Un esempio del campo è:

       If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Se la richiesta normalmente (cioè senza l'intestazione If-Unmodified-Since) darebbe come risultato qualcosa di diverso da uno stato 2xx o 412, l'intestazione If-Unmodified-Since dovrebbe (SHOULD) essere ignorata.

Se la data specificata non è valida, l'intestazione viene ignorata.

Il risultato di una richiesta che presenti sia un campo di intestazione If-Unmodified-Since sia un campo di intestazione If-None-Match o If-Modified-Since non è definito da questa specifica.

14.29 Last-Modified

Il campo di intestazione di entità Last-Modified indica la data e l'ora in cui il server di origine ritiene che la variante sia stata modificata l'ultima volta.

       Last-Modified  = "Last-Modified" ":" HTTP-date

Un esempio del suo uso è

       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Il significato esatto di questo campo di intestazione dipende dall'implementazione del server di origine e dalla natura della risorsa originale. Per i file, può essere semplicemente l'ora di ultima modifica del file system. Per le entità con parti incluse dinamicamente, può essere la più recente dell'insieme di orari di ultima modifica delle sue parti componenti. Per i gateway di database, può essere il timestamp di ultimo aggiornamento del record. Per gli oggetti virtuali, può essere l'ultima volta in cui lo stato interno è cambiato.

Un server di origine non deve (MUST NOT) inviare una data Last-Modified successiva all'ora di origine del messaggio del server. In tali casi, in cui l'ultima modifica della risorsa indicherebbe un momento nel futuro, il server deve (MUST) sostituire quella data con la data di origine del messaggio.

Un server di origine dovrebbe (SHOULD) ottenere il valore Last-Modified dell'entità il più vicino possibile al momento in cui genera il valore Date della sua risposta. Ciò consente a un destinatario di formulare una valutazione accurata dell'ora di modifica dell'entità, specialmente se l'entità cambia in prossimità del momento in cui la risposta viene generata.

I server HTTP/1.1 dovrebbero (SHOULD) inviare Last-Modified ogni volta che è fattibile.

14.30 Location

Il campo di intestazione di risposta Location viene usato per reindirizzare il destinatario verso una posizione diversa dalla Request-URI, per il completamento della richiesta o per l'identificazione di una nuova risorsa. Per le risposte 201 (Created), la Location è quella della nuova risorsa creata dalla richiesta. Per le risposte 3xx, la location dovrebbe (SHOULD) indicare la URI preferita dal server per il reindirizzamento automatico alla risorsa. Il valore del campo è costituito da una singola URI assoluta.

       Location       = "Location" ":" absoluteURI

Un esempio è:

       Location: http://www.w3.org/pub/WWW/People.html

Nota: il campo di intestazione Content-Location (sezione 14.14) differisce da Location in quanto Content-Location identifica la posizione originale dell'entità racchiusa nella richiesta. È quindi possibile che una risposta contenga campi di intestazione sia per Location sia per Content-Location. Vedere anche la sezione 13.10 per i requisiti di caching di alcuni metodi.

14.31 Max-Forwards

Il campo di intestazione di richiesta Max-Forwards fornisce, con i metodi TRACE (sezione 9.8) e OPTIONS (sezione 9.2), un meccanismo per limitare il numero di proxy o gateway che possono inoltrare la richiesta al server in ingresso successivo. Ciò può essere utile quando il client sta tentando di tracciare una catena di richieste che sembra fallire o entrare in un ciclo a metà catena.

       Max-Forwards   = "Max-Forwards" ":" 1*DIGIT

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

Ogni destinatario proxy o gateway di 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), il destinatario non deve (MUST NOT) inoltrare la richiesta; deve (MUST) invece rispondere come destinatario finale. Se il valore Max-Forwards ricevuto è maggiore di zero, allora il messaggio inoltrato deve (MUST) contenere un campo Max-Forwards aggiornato con un valore decrementato di uno (1).

Il campo di intestazione Max-Forwards può (MAY) essere ignorato per tutti gli altri metodi definiti da questa specifica e per qualsiasi metodo di estensione per il quale non sia esplicitamente richiamato come parte della definizione di quel metodo.

14.32 Pragma

Il campo di intestazione generale Pragma viene usato per includere direttive specifiche dell'implementazione che potrebbero applicarsi a qualsiasi destinatario lungo la catena richiesta/risposta. Tutte le direttive pragma specificano un comportamento facoltativo dal punto di vista del protocollo; tuttavia, alcuni sistemi possono (MAY) richiedere che il comportamento sia coerente con le direttive.

       Pragma            = "Pragma" ":" 1#pragma-directive
       pragma-directive  = "no-cache" | extension-pragma
       extension-pragma  = token [ "=" ( token | quoted-string ) ]

Quando la direttiva no-cache è presente in un messaggio di richiesta, un'applicazione dovrebbe (SHOULD) inoltrare la richiesta verso il server di origine anche se possiede una copia memorizzata in cache di ciò che viene richiesto. Questa direttiva pragma ha la stessa semantica della direttiva di cache no-cache (vedere la sezione 14.9) ed è definita qui per compatibilità all'indietro con HTTP/1.0. I client dovrebbero (SHOULD) includere entrambi i campi di intestazione quando una richiesta no-cache viene inviata a un server non noto come conforme a HTTP/1.1.

Le direttive Pragma devono (MUST) essere propagate attraverso un'applicazione proxy o gateway, indipendentemente dal loro significato per tale applicazione, poiché le direttive potrebbero essere applicabili a tutti i destinatari lungo la catena richiesta/risposta. Non è possibile specificare un pragma per un destinatario particolare; tuttavia, qualsiasi direttiva pragma non pertinente a un destinatario dovrebbe (SHOULD) essere ignorata da quel destinatario.

Le cache HTTP/1.1 dovrebbero (SHOULD) trattare "Pragma: no-cache" come se il client avesse inviato "Cache-Control: no-cache". In HTTP non verranno definite nuove direttive Pragma.

Nota: poiché il significato di "Pragma: no-cache" come campo di intestazione di risposta non è in realtà specificato, esso non fornisce un sostituto affidabile di "Cache-Control: no-cache" in una risposta.

14.33 Proxy-Authenticate

Il campo di intestazione di risposta Proxy-Authenticate deve (MUST) essere incluso come parte di una risposta 407 (Proxy Authentication Required). Il valore del campo è costituito da una challenge che indica lo schema di autenticazione e i parametri applicabili al proxy per questa Request-URI.

       Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge

Il processo di autenticazione di accesso HTTP è descritto in "HTTP Authentication: Basic and Digest Access Authentication" [43]. A differenza di WWW-Authenticate, il campo di intestazione Proxy-Authenticate si applica soltanto alla connessione corrente e non dovrebbe (SHOULD NOT) essere passato ai client a valle. Tuttavia, un proxy intermedio potrebbe aver bisogno di ottenere le proprie credenziali richiedendole al client a valle, il che in alcune circostanze apparirà come se il proxy stesse inoltrando il campo di intestazione Proxy-Authenticate.

14.34 Proxy-Authorization

Il campo di intestazione di richiesta Proxy-Authorization consente al client di identificare se stesso (o il proprio utente) presso un proxy che richiede autenticazione. Il valore del campo Proxy-Authorization è costituito da credenziali che contengono le informazioni di autenticazione dello user agent per il proxy e/o il realm della risorsa richiesta.

       Proxy-Authorization     = "Proxy-Authorization" ":" credentials

Il processo di autenticazione di accesso HTTP è descritto in "HTTP Authentication: Basic and Digest Access Authentication" [43]. A differenza di Authorization, il campo di intestazione Proxy-Authorization si applica soltanto al proxy in uscita successivo che ha richiesto l'autenticazione usando il campo Proxy-Authenticate. Quando in una catena si usano più proxy, il campo di intestazione Proxy-Authorization viene consumato dal primo proxy in uscita che si aspettava di ricevere le credenziali. Un proxy può (MAY) ritrasmettere le credenziali dalla richiesta del client al proxy successivo, se è questo il meccanismo con cui i proxy autenticano in modo cooperativo una data richiesta.

14.35 Range

14.35.1 Byte Ranges (Intervalli di Byte)

Poiché tutte le entità HTTP sono rappresentate nei messaggi HTTP come sequenze di byte, il concetto di intervallo di byte (byte range) è significativo per qualsiasi entità HTTP. (Tuttavia, non tutti i client e i server devono necessariamente supportare le operazioni su intervalli di byte.)

Le specifiche di intervallo di byte in HTTP si applicano alla sequenza di byte dell'entità-body (non necessariamente uguale al message-body).

Un'operazione su intervalli di byte può (MAY) specificare un singolo intervallo di byte, oppure un insieme di intervalli all'interno di una singola entità.

       ranges-specifier = byte-ranges-specifier
       byte-ranges-specifier = bytes-unit "=" byte-range-set
       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
       byte-range-spec = first-byte-pos "-" [last-byte-pos]
       first-byte-pos  = 1*DIGIT
       last-byte-pos   = 1*DIGIT

Il valore first-byte-pos in un byte-range-spec fornisce l'offset in byte del primo byte di un intervallo. Il valore last-byte-pos fornisce l'offset in byte dell'ultimo byte dell'intervallo; vale a dire che le posizioni in byte specificate sono inclusive. Gli offset in byte iniziano da zero.

Se il valore last-byte-pos è presente, deve (MUST) essere maggiore o uguale al first-byte-pos in quel byte-range-spec, altrimenti il byte-range-spec è sintatticamente non valido. Il destinatario di un byte-range-set che includa uno o più valori byte-range-spec sintatticamente non validi deve (MUST) ignorare il campo di intestazione che include quel byte-range-set.

Se il valore last-byte-pos è assente, oppure se il valore è maggiore o uguale alla lunghezza corrente dell'entità-body, si considera last-byte-pos uguale a uno meno la lunghezza corrente dell'entità-body in byte.

Mediante la scelta di last-byte-pos, un client può limitare il numero di byte recuperati senza conoscere la dimensione dell'entità.

       suffix-byte-range-spec = "-" suffix-length
       suffix-length = 1*DIGIT

Un suffix-byte-range-spec viene usato per specificare il suffisso dell'entità-body, di lunghezza pari al valore suffix-length. (Vale a dire che questa forma specifica gli ultimi N byte di un'entità-body.) Se l'entità è più corta della suffix-length specificata, si usa l'intera entità-body.

Se un byte-range-set sintatticamente valido include almeno un byte-range-spec il cui first-byte-pos sia minore della lunghezza corrente dell'entità-body, oppure almeno un suffix-byte-range-spec con una suffix-length diversa da zero, allora il byte-range-set è soddisfacibile. In caso contrario, il byte-range-set non è soddisfacibile. Se il byte-range-set non è soddisfacibile, il server dovrebbe (SHOULD) restituire una risposta con uno stato 416 (Requested range not satisfiable). In caso contrario, il server dovrebbe (SHOULD) restituire una risposta con uno stato 206 (Partial Content) contenente gli intervalli soddisfacibili dell'entità-body.

Esempi di valori byte-ranges-specifier (supponendo un'entità-body di lunghezza 10000):

      - The first 500 bytes (byte offsets 0-499, inclusive):  bytes=0-
        499

      - The second 500 bytes (byte offsets 500-999, inclusive):
        bytes=500-999

      - The final 500 bytes (byte offsets 9500-9999, inclusive):
        bytes=-500

      - Or bytes=9500-

      - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1

      - Several legal but not canonical specifications of the second 500
        bytes (byte offsets 500-999, inclusive):
         bytes=500-600,601-999
         bytes=500-700,601-999

14.35.2 Range Retrieval Requests (Richieste di Recupero per Intervallo)

Le richieste di recupero HTTP che usano metodi GET condizionali o incondizionali possono (MAY) richiedere uno o più sottointervalli dell'entità, invece dell'entità completa, usando l'intestazione di richiesta Range, che si applica all'entità restituita come risultato della richiesta:

      Range = "Range" ":" ranges-specifier

Un server può (MAY) ignorare l'intestazione Range. Tuttavia, i server di origine HTTP/1.1 e le cache intermedie dovrebbero supportare gli intervalli di byte quando possibile, poiché Range consente un recupero efficiente da trasferimenti parzialmente falliti e supporta il recupero parziale efficiente di entità di grandi dimensioni.

Se il server supporta l'intestazione Range e l'intervallo o gli intervalli specificati sono appropriati per l'entità:

• La presenza di un'intestazione Range in una GET incondizionale modifica ciò che viene restituito se la GET ha altrimenti successo. In altre parole, la risposta porta un codice di stato 206 (Partial Content) invece di 200 (OK).

• La presenza di un'intestazione Range in una GET condizionale (una richiesta che usi If-Modified-Since e/o If-None-Match, oppure If-Unmodified-Since e/o If-Match) modifica ciò che viene restituito se la GET ha altrimenti successo e la condizione è vera. Non influisce sulla risposta 304 (Not Modified) restituita se il condizionale è falso.

In alcuni casi, potrebbe essere più appropriato usare l'intestazione If-Range (vedere la sezione 14.27) oltre all'intestazione Range.

Se un proxy che supporta gli intervalli riceve una richiesta Range, inoltra la richiesta a un server in ingresso e riceve in risposta un'entità completa, dovrebbe (SHOULD) restituire al proprio client soltanto l'intervallo richiesto. Dovrebbe (SHOULD) memorizzare l'intera risposta ricevuta nella propria cache, se ciò è coerente con le proprie politiche di allocazione della cache.

14.36 Referer

Il campo di intestazione di richiesta Referer[sic] consente al client di specificare, a beneficio del server, l'indirizzo (URI) della risorsa dalla quale è stata ottenuta la Request-URI (il "referrer", sebbene il campo di intestazione sia scritto in modo errato). L'intestazione di richiesta Referer consente a un server di generare elenchi di back-link a risorse per interesse, registrazione, caching ottimizzato, ecc. Consente inoltre di rintracciare, a fini di manutenzione, link obsoleti o digitati in modo errato. Il campo Referer non deve (MUST NOT) essere inviato se la Request-URI è stata ottenuta da una fonte che non ha una propria URI, come l'input dalla tastiera dell'utente.

       Referer        = "Referer" ":" ( absoluteURI | relativeURI )

Esempio:

       Referer: http://www.w3.org/hypertext/DataSources/Overview.html

Se il valore del campo è una URI relativa, dovrebbe (SHOULD) essere interpretata rispetto alla Request-URI. La URI non deve (MUST NOT) includere un frammento. Per le considerazioni sulla sicurezza, vedere la sezione 15.1.3.

14.37 Retry-After

Il campo di intestazione di risposta Retry-After può essere usato con una risposta 503 (Service Unavailable) per indicare per quanto tempo si prevede che il servizio sarà indisponibile per il client richiedente. Questo campo può (MAY) essere usato anche con qualsiasi risposta 3xx (Redirection) per indicare il tempo minimo che si chiede allo user-agent di attendere prima di emettere la richiesta reindirizzata. Il valore di questo campo può essere una HTTP-date oppure un numero intero di secondi (in decimale) dopo il momento della risposta.

       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

Due esempi del suo uso sono

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

Nel secondo esempio, il ritardo è di 2 minuti.

14.38 Server

Il campo di intestazione di risposta Server contiene informazioni sul software usato dal server di origine per gestire la richiesta. Il campo può contenere più product token (sezione 3.8) e commenti che identificano il server e gli eventuali sottoprodotti significativi. I product token sono elencati in ordine di importanza per l'identificazione dell'applicazione.

       Server         = "Server" ":" 1*( product | comment )

Esempio:

       Server: CERN/3.0 libwww/2.17

Se la risposta viene inoltrata attraverso un proxy, l'applicazione proxy non deve (MUST NOT) modificare l'intestazione di risposta Server. Dovrebbe (SHOULD) invece includere un campo Via (come descritto nella sezione 14.45).

Nota: rivelare la versione specifica del software del server potrebbe rendere la macchina server più vulnerabile ad attacchi contro software noto per contenere falle di sicurezza. Si incoraggiano gli implementatori di server a rendere questo campo un'opzione configurabile.

14.39 TE

Il campo di intestazione di richiesta TE indica quali transfer-coding di estensione è disposto ad accettare nella risposta e se è disposto o meno ad accettare campi trailer in una transfer-coding chunked. Il suo valore può essere costituito dalla parola chiave "trailers" e/o da un elenco separato da virgole di nomi di transfer-coding di estensione con parametri di accettazione facoltativi (come descritto nella sezione 3.6).

       TE        = "TE" ":" #( t-codings )
       t-codings = "trailers" | ( transfer-extension [ accept-params ] )

La presenza della parola chiave "trailers" indica che il client è disposto ad accettare campi trailer in una transfer-coding chunked, come definito nella sezione 3.6.1. Questa parola chiave è riservata all'uso con valori di transfer-coding, anche se di per sé non rappresenta una transfer-coding.

Esempi del suo uso sono:

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

Il campo di intestazione TE si applica soltanto alla connessione immediata. Pertanto, la parola chiave deve (MUST) essere fornita all'interno di un campo di intestazione Connection (sezione 14.10) ogni volta che TE è presente in un messaggio HTTP/1.1.

Un server verifica se una transfer-coding è accettabile, secondo un campo TE, usando queste regole:

1. La transfer-coding "chunked" è sempre accettabile. Se è elencata la parola chiave "trailers", il client indica che è disposto ad accettare campi trailer nella risposta chunked per conto proprio e di qualsiasi client a valle. L'implicazione è che, se presente, il client sta dichiarando che tutti i client a valle sono disposti ad accettare campi trailer nella risposta inoltrata, oppure che tenterà di bufferizzare la risposta per conto dei destinatari a valle.

   Nota: HTTP/1.1 non definisce alcun mezzo per limitare la dimensione di una risposta chunked in modo che un client possa avere la garanzia di bufferizzare l'intera risposta.

2. Se la transfer-coding in esame è una delle transfer-coding elencate nel campo TE, allora è accettabile, a meno che non sia accompagnata da un qvalue pari a 0. (Come definito nella sezione 3.9, un qvalue pari a 0 significa "non accettabile".)

3. Se più transfer-coding sono accettabili, viene preferita la transfer-coding accettabile con il qvalue non nullo più alto. Alla transfer-coding "chunked" è sempre assegnato un qvalue pari a 1.

Se il valore del campo TE è vuoto, o se non è presente alcun campo TE, l'unica transfer-coding è "chunked". Un messaggio senza transfer-coding è sempre accettabile.

14.40 Trailer

Il valore del campo generale Trailer indica che l'insieme di campi di intestazione indicato è presente nel trailer di un messaggio codificato con transfer-coding chunked.

       Trailer  = "Trailer" ":" 1#field-name

Un messaggio HTTP/1.1 dovrebbe (SHOULD) includere un campo di intestazione Trailer in un messaggio che usa la transfer-coding chunked con un trailer non vuoto. Ciò consente al destinatario di sapere quali campi di intestazione aspettarsi nel trailer.

Se non è presente alcun campo di intestazione Trailer, il trailer non dovrebbe (SHOULD NOT) includere alcun campo di intestazione. Per le restrizioni sull'uso dei campi trailer in una transfer-coding "chunked", vedere la sezione 3.6.1.

I campi di intestazione del messaggio elencati nel campo di intestazione Trailer non devono (MUST NOT) includere i seguenti campi di intestazione:

• Transfer-Encoding

• Content-Length

• Trailer

14.41 Transfer-Encoding

Il campo di intestazione generale Transfer-Encoding indica quale tipo di trasformazione (se presente) è stata applicata al corpo del messaggio al fine di trasferirlo in modo sicuro tra il mittente e il destinatario. Ciò differisce dalla content-coding in quanto la transfer-coding è una proprietà del messaggio, non dell'entità.

     Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding

Le transfer-coding sono definite nella sezione 3.6. Un esempio è:

     Transfer-Encoding: chunked

Se a un'entità sono state applicate più codifiche, le transfer-coding devono (MUST) essere elencate nell'ordine in cui sono state applicate. Informazioni aggiuntive sui parametri di codifica possono (MAY) essere fornite da altri campi di intestazione di entità non definiti da questa specifica.

Molte applicazioni HTTP/1.0 più vecchie non comprendono l'intestazione Transfer-Encoding.

14.42 Upgrade

L'intestazione generale Upgrade consente al client di specificare quali protocolli di comunicazione aggiuntivi supporta e desidera usare qualora il server ritenga appropriato cambiare protocollo. Il server deve (MUST) usare il campo di intestazione Upgrade all'interno di una risposta 101 (Switching Protocols) per indicare quale o quali protocolli vengono cambiati.

       Upgrade        = "Upgrade" ":" 1#product

Per esempio,

       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Il campo di intestazione Upgrade è inteso a fornire un meccanismo semplice per la transizione da HTTP/1.1 a qualche altro protocollo incompatibile. Esso lo fa consentendo al client di annunciare il proprio desiderio di usare un altro protocollo, come una versione successiva di HTTP con un numero di versione principale più alto, anche se la richiesta corrente è stata effettuata usando HTTP/1.1. Ciò agevola la difficile transizione tra protocolli incompatibili, consentendo al client di avviare una richiesta con il protocollo più comunemente supportato mentre indica al server che desidererebbe usare un protocollo "migliore", se disponibile (dove "migliore" è determinato dal server, eventualmente in base alla natura del metodo e/o della risorsa richiesta).

Il campo di intestazione Upgrade si applica soltanto al cambio di protocolli a livello applicativo sulla connessione di livello trasporto esistente. Upgrade non può essere usato per imporre un cambio di protocollo; la sua accettazione e il suo uso da parte del server sono facoltativi. Le capacità e la natura della comunicazione a livello applicativo dopo il cambio di protocollo dipendono interamente dal nuovo protocollo scelto, sebbene la prima azione dopo il cambio di protocollo debba (MUST) essere una risposta alla richiesta HTTP iniziale contenente il campo di intestazione Upgrade.

Il campo di intestazione Upgrade si applica soltanto alla connessione immediata. Pertanto, la parola chiave upgrade deve (MUST) essere fornita all'interno di un campo di intestazione Connection (sezione 14.10) ogni volta che Upgrade è presente in un messaggio HTTP/1.1.

Il campo di intestazione Upgrade non può essere usato per indicare un passaggio a un protocollo su una connessione diversa. Per tale scopo è più appropriato usare una risposta di reindirizzamento 301, 302, 303 o 305.

Questa specifica definisce soltanto il nome di protocollo "HTTP" per l'uso da parte della famiglia di protocolli Hypertext Transfer, come definito dalle regole di versione di HTTP della sezione 3.1 e da futuri aggiornamenti di questa specifica. Qualsiasi token può essere usato come nome di protocollo; tuttavia, sarà utile solo se sia il client sia il server associano il nome allo stesso protocollo.

14.43 User-Agent

Il campo di intestazione di richiesta User-Agent contiene informazioni sullo user agent che ha originato la richiesta. Ciò serve a fini statistici, al tracciamento delle violazioni del protocollo e al riconoscimento automatico degli user agent al fine di adattare le risposte per evitare particolari limitazioni degli user agent. Gli user agent dovrebbero (SHOULD) includere questo campo nelle richieste. Il campo può contenere più product token (sezione 3.8) e commenti che identificano l'agente e gli eventuali sottoprodotti che costituiscono una parte significativa dello user agent. Per convenzione, i product token sono elencati in ordine di importanza per l'identificazione dell'applicazione.

       User-Agent     = "User-Agent" ":" 1*( product | comment )

Esempio:

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

14.44 Vary

Il valore del campo Vary indica l'insieme di campi di intestazione di richiesta che determina pienamente, finché la risposta è fresca, se a una cache è consentito usare la risposta per replicare a una richiesta successiva senza rivalidazione. Per le risposte non memorizzabili in cache o obsolete, il valore del campo Vary informa lo user agent circa i criteri usati per selezionare la rappresentazione. Un valore del campo Vary pari a "*" implica che una cache non può determinare, dalle intestazioni di richiesta di una richiesta successiva, se questa risposta sia la rappresentazione appropriata. Per l'uso del campo di intestazione Vary da parte delle cache, vedere la sezione 13.6.

       Vary  = "Vary" ":" ( "*" | 1#field-name )

Un server HTTP/1.1 dovrebbe (SHOULD) includere un campo di intestazione Vary con qualsiasi risposta memorizzabile in cache soggetta a negoziazione guidata dal server. Ciò consente a una cache di interpretare correttamente le richieste future su quella risorsa e informa lo user agent della presenza di negoziazione su quella risorsa. Un server può (MAY) includere un campo di intestazione Vary con una risposta non memorizzabile in cache soggetta a negoziazione guidata dal server, poiché ciò potrebbe fornire allo user agent informazioni utili sulle dimensioni rispetto alle quali la risposta varia al momento della risposta.

Un valore del campo Vary costituito da un elenco di field-name segnala che la rappresentazione selezionata per la risposta si basa su un algoritmo di selezione che considera SOLTANTO i valori dei campi di intestazione di richiesta elencati nel selezionare la rappresentazione più appropriata. Una cache può (MAY) presumere che la stessa selezione verrà effettuata per richieste future con gli stessi valori dei field name elencati, per tutta la durata in cui la risposta è fresca.

I field name forniti non sono limitati all'insieme dei campi di intestazione di richiesta standard definiti da questa specifica. I nomi dei campi non distinguono tra maiuscole e minuscole.

Un valore del campo Vary pari a "" segnala che parametri non specificati, non limitati alle intestazioni di richiesta (per esempio l'indirizzo di rete del client), svolgono un ruolo nella selezione della rappresentazione della risposta. Il valore "" non deve (MUST NOT) essere generato da un server proxy; può essere generato soltanto da un server di origine.

14.45 Via

Il campo di intestazione generale Via deve (MUST) essere usato da gateway e proxy per indicare i protocolli e i destinatari intermedi tra lo user agent e il server sulle richieste, e tra il server di origine e il client sulle risposte. È analogo al campo "Received" di RFC 822 [9] ed è inteso a essere usato per tracciare gli inoltri dei messaggi, evitare cicli di richieste e identificare le capacità di protocollo di tutti i mittenti lungo la catena richiesta/risposta.

      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
      received-protocol = [ protocol-name "/" ] protocol-version
      protocol-name     = token
      protocol-version  = token
      received-by       = ( host [ ":" port ] ) | pseudonym
      pseudonym         = token

Il received-protocol indica la versione di protocollo del messaggio ricevuto dal server o dal client lungo ciascun segmento della catena richiesta/risposta. La versione received-protocol viene accodata al valore del campo Via quando il messaggio viene inoltrato, in modo che le informazioni sulle capacità di protocollo delle applicazioni a monte restino visibili a tutti i destinatari.

Il protocol-name è facoltativo se e solo se sarebbe "HTTP". Il campo received-by è normalmente l'host e il numero di porta facoltativo di un server o client destinatario che ha successivamente inoltrato il messaggio. Tuttavia, se l'host reale è considerato un'informazione sensibile, può (MAY) essere sostituito da uno pseudonimo. Se la porta non è fornita, può (MAY) essere presupposta la porta predefinita del received-protocol.

Valori multipli del campo Via rappresentano ciascun proxy o gateway che ha inoltrato il messaggio. Ogni destinatario deve (MUST) accodare le proprie informazioni in modo che il risultato finale sia ordinato secondo la sequenza delle applicazioni che hanno inoltrato il messaggio.

I commenti possono (MAY) essere usati nel campo di intestazione Via per identificare il software del proxy o gateway destinatario, in modo analogo ai campi di intestazione User-Agent e Server. Tuttavia, tutti i commenti nel campo Via sono facoltativi e possono (MAY) essere rimossi da qualsiasi destinatario prima di inoltrare il messaggio.

Per esempio, un messaggio di richiesta potrebbe essere inviato da uno user agent HTTP/1.0 a un proxy interno denominato in codice "fred", che usa HTTP/1.1 per inoltrare la richiesta a un proxy pubblico presso nowhere.com, il quale completa la richiesta inoltrandola al server di origine presso www.ics.uci.edu. La richiesta ricevuta da www.ics.uci.edu avrebbe allora il seguente campo di intestazione Via:

       Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

I proxy e i gateway usati come portale attraverso un firewall di rete non dovrebbero (SHOULD NOT), per impostazione predefinita, inoltrare i nomi e le porte degli host all'interno della regione del firewall. Queste informazioni dovrebbero (SHOULD) essere propagate solo se esplicitamente abilitate. Se non sono abilitate, l'host received-by di qualsiasi host dietro il firewall dovrebbe (SHOULD) essere sostituito da uno pseudonimo appropriato per quell'host.

Per le organizzazioni che hanno forti requisiti di privacy relativi alla necessità di nascondere le strutture interne, un proxy può (MAY) combinare una sottosequenza ordinata di voci del campo di intestazione Via con valori received-protocol identici in un'unica voce di tal genere. Per esempio,

       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

potrebbe essere ridotto a

       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Le applicazioni non dovrebbero (SHOULD NOT) combinare più voci, a meno che non siano tutte sotto il medesimo controllo organizzativo e gli host siano già stati sostituiti da pseudonimi. Le applicazioni non devono (MUST NOT) combinare voci che abbiano valori received-protocol diversi.

14.46 Warning

Il campo di intestazione generale Warning viene usato per trasportare informazioni aggiuntive sullo stato o sulla trasformazione di un messaggio che potrebbero non essere riflesse nel messaggio stesso. Queste informazioni vengono tipicamente usate per avvisare di una possibile mancanza di trasparenza semantica dovuta a operazioni di caching o a trasformazioni applicate al corpo dell'entità del messaggio.

Le intestazioni Warning vengono inviate con le risposte usando:

       Warning    = "Warning" ":" 1#warning-value

       warning-value = warn-code SP warn-agent SP warn-text
                                             [SP warn-date]

       warn-code  = 3DIGIT
       warn-agent = ( host [ ":" port ] ) | pseudonym
                       ; the name or pseudonym of the server adding
                       ; the Warning header, for use in debugging
       warn-text  = quoted-string
       warn-date  = `<">` HTTP-date `<">`

Una risposta può (MAY) portare più di un'intestazione Warning.

Il warn-text dovrebbe (SHOULD) essere in una lingua naturale e in un insieme di caratteri che abbiano la maggiore probabilità di essere intelligibili per l'utente umano che riceve la risposta. Questa decisione può (MAY) basarsi su qualsiasi conoscenza disponibile, come l'ubicazione della cache o dell'utente, il campo Accept-Language in una richiesta, il campo Content-Language in una risposta, ecc. La lingua predefinita è l'inglese e l'insieme di caratteri predefinito è ISO-8859-1.

Se viene usato un insieme di caratteri diverso da ISO-8859-1, esso deve (MUST) essere codificato nel warn-text usando il metodo descritto in RFC 2047 [14].

In generale, le intestazioni Warning possono essere applicate a qualsiasi messaggio; tuttavia alcuni warn-code specifici sono propri delle cache e possono essere applicati soltanto a messaggi di risposta. Le nuove intestazioni Warning dovrebbero (SHOULD) essere aggiunte dopo le intestazioni Warning già esistenti. Una cache non deve (MUST NOT) eliminare alcuna intestazione Warning ricevuta con un messaggio. Tuttavia, se una cache valida con successo una voce di cache, dovrebbe (SHOULD) rimuovere qualsiasi intestazione Warning precedentemente allegata a quella voce, salvo quanto specificato per codici Warning particolari. Deve (MUST) poi aggiungere qualsiasi intestazione Warning ricevuta nella risposta di validazione. In altre parole, le intestazioni Warning sono quelle che sarebbero allegate alla più recente risposta pertinente.

Quando a una risposta sono allegate più intestazioni Warning, lo user agent dovrebbe informare l'utente di quante più possibile, nell'ordine in cui compaiono nella risposta. Se non è possibile informare l'utente di tutti gli avvisi, lo user agent dovrebbe (SHOULD) seguire queste euristiche:

• Gli avvisi che compaiono all'inizio della risposta hanno priorità su quelli che compaiono più avanti nella risposta.

• Gli avvisi nell'insieme di caratteri preferito dall'utente hanno priorità sugli avvisi in altri insiemi di caratteri ma con warn-code e warn-agent identici.

I sistemi che generano più intestazioni Warning dovrebbero (SHOULD) ordinarle tenendo presente questo comportamento dello user agent.

I requisiti per il comportamento delle cache rispetto ai Warning sono enunciati nella sezione 13.1.2.

Questo è un elenco dei warn-code attualmente definiti, ciascuno con un warn-text raccomandato in inglese e una descrizione del suo significato.

110 Response is stale Deve (MUST) essere incluso ogni volta che la risposta restituita è obsoleta.

111 Revalidation failed Deve (MUST) essere incluso se una cache restituisce una risposta obsoleta perché un tentativo di rivalidare la risposta è fallito, a causa dell'impossibilità di raggiungere il server.

112 Disconnected operation Dovrebbe (SHOULD) essere incluso se la cache è intenzionalmente disconnessa dal resto della rete per un periodo di tempo.

113 Heuristic expiration Deve (MUST) essere incluso se la cache ha scelto euristicamente una durata di freschezza maggiore di 24 ore e l'età della risposta è maggiore di 24 ore.

199 Miscellaneous warning Il testo dell'avviso può (MAY) includere informazioni arbitrarie da presentare a un utente umano, oppure da registrare. Un sistema che riceve questo avviso non deve (MUST NOT) intraprendere alcuna azione automatica, oltre a presentare l'avviso all'utente.

214 Transformation applied Deve (MUST) essere aggiunto da una cache intermedia o da un proxy se applica una qualsiasi trasformazione che modifichi la content-coding (come specificata nell'intestazione Content-Encoding) o il media-type (come specificato nell'intestazione Content-Type) della risposta, oppure l'entità-body della risposta, a meno che questo codice Warning compaia già nella risposta.

299 Miscellaneous persistent warning Il testo dell'avviso può (MAY) includere informazioni arbitrarie da presentare a un utente umano, oppure da registrare. Un sistema che riceve questo avviso non deve (MUST NOT) intraprendere alcuna azione automatica.

Se un'implementazione invia un messaggio con una o più intestazioni Warning la cui versione è HTTP/1.0 o inferiore, allora il mittente deve (MUST) includere in ogni warning-value un warn-date che corrisponda alla data nella risposta.

Se un'implementazione riceve un messaggio con un warning-value che include un warn-date, e quel warn-date è diverso dal valore Date nella risposta, allora quel warning-value deve (MUST) essere eliminato dal messaggio prima di memorizzarlo, inoltrarlo o usarlo. (Ciò previene conseguenze negative derivanti da un caching ingenuo dei campi di intestazione Warning.) Se tutti i warning-value vengono eliminati per questo motivo, anche l'intestazione Warning deve (MUST) essere eliminata.

14.47 WWW-Authenticate

Il campo di intestazione di risposta WWW-Authenticate deve (MUST) essere incluso nei messaggi di risposta 401 (Unauthorized). Il valore del campo è costituito da almeno una challenge che indica lo schema o gli schemi di autenticazione e i parametri applicabili alla Request-URI.

       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

Il processo di autenticazione di accesso HTTP è descritto in "HTTP Authentication: Basic and Digest Access Authentication" [43]. Si consiglia agli user agent di prestare particolare attenzione nell'analizzare il valore del campo WWW-Authenticate, poiché esso potrebbe contenere più di una challenge oppure, se viene fornito più di un campo di intestazione WWW-Authenticate, il contenuto di una challenge stessa può contenere un elenco di parametri di autenticazione separati da virgole.