2.1. Campi HTTP (HTTP Fields)

2.1. Campi HTTP (HTTP Fields)

Il nome del componente per un campo HTTP è la forma in minuscolo del suo nome di campo come definito nella Sezione 5.1 di [HTTP]. Sebbene i nomi dei campi HTTP siano insensibili alle maiuscole, le implementazioni DEVONO usare nomi di campo in minuscolo (ad esempio content-type, date, etag) quando li usano come nomi di componente.

Il valore del componente per un campo HTTP è il valore di campo per il campo nominato come definito nella Sezione 5.5 di [HTTP]. Il valore di campo DEVE essere preso dal campo di intestazione nominato del messaggio di destinazione, salvo che questo comportamento non sia sovrascritto da parametri e regole aggiuntivi, come i flag req e tr, di seguito. Per la maggior parte dei campi, il valore di campo è una stringa ASCII come raccomandato da [HTTP], e il valore del componente è esattamente quella stringa. Altre codifiche possono esistere in alcune implementazioni, e tutti i valori di campo non ASCII DEVONO essere codificati in ASCII prima di essere aggiunti alla base della firma. Il parametro bs, come descritto nella Sezione 2.1.3, fornisce un metodo per avvolgere tali valori di campo problematici.

Salvo diversa disposizione di parametri e regole aggiuntivi, i valori dei campi HTTP DEVONO essere combinati in un singolo valore come definito nella Sezione 5.2 di [HTTP] per creare il valore del componente. In particolare, i campi HTTP inviati come campi multipli DEVONO essere combinati concatenando i valori usando una singola virgola e un singolo spazio come separatore ("," + " "). Si noti che gli intermediari possono combinare valori di campi HTTP con qualsiasi quantità di spazi bianchi tra le virgole, e se questo comportamento non è considerato dal verificatore, la firma può fallire, poiché firmatario e verificatore vedranno un valore di componente diverso nelle rispettive basi della firma. Per robustezza, è RACCOMANDATO che i messaggi firmati includano una sola istanza di ogni campo coperto dalla firma, in particolare con il valore per campi basati su lista serializzato usando l'algoritmo di seguito. Questo approccio aumenta la probabilità che il valore del campo resti inalterato attraverso gli intermediari. Ove tale approccio non sia possibile e occorra inviare separatamente più istanze di un campo, è RACCOMANDATO che firmatari e verificatori elaborino i campi basati su lista prendendo tutti i valori di campo individuali e combinandoli secondo l'algoritmo rigoroso di seguito, per contrastare il possibile comportamento degli intermediari. Quando il campo in questione è un Structured Field di tipo List o Dictionary, questo effetto può essere ottenuto più direttamente richiedendo la serializzazione rigorosa Structured Field del valore di campo, come descritto nella Sezione 2.1.1.

Si noti che alcuni campi HTTP, come Set-Cookie [COOKIE], non seguono una sintassi che consenta la combinazione dei valori di campo in questo modo (in modo che l'output combinato sia non ambiguo rispetto a input multipli). Anche se il valore del componente non viene mai analizzato dal processo di firma del messaggio ed è usato solo come parte della base della firma (Sezione 2.5), occorre cautela nell'includere tali campi nelle firme, poiché il valore combinato potrebbe essere ambiguo. Il parametro bs, come descritto nella Sezione 2.1.3, fornisce un metodo per avvolgere tali campi problematici. Si veda la Sezione 7.5.6 per ulteriori discussioni su questo problema.

Se il valore combinato corretto non è direttamente disponibile per un dato campo in un'implementazione, il seguente algoritmo produrrà risultati canonicalizzati per campi basati su lista:

1. Creare un elenco ordinato dei valori di campo di ciascuna istanza del campo nel messaggio, nell'ordine in cui compaiono (o compariranno) nel messaggio.

2. Rimuovere gli spazi bianchi iniziali e finali da ogni elemento dell'elenco. Si noti che poiché i valori dei campi HTTP non possono contenere spazi bianchi iniziali e finali, questo sarebbe un no-op in un'implementazione conforme.

3. Rimuovere qualsiasi line folding obsoleto nella riga e sostituirlo con un singolo spazio (" "), come discusso nella Sezione 5.2 di [HTTP/1.1]. Si noti che questo comportamento è specifico di HTTP/1.1 e non si applica ad altre versioni della specifica HTTP, che non consentono line folding interno.

4. Concatenare l'elenco di valori con una singola virgola (",") e un singolo spazio (" ") tra ogni elemento.

La stringa risultante è il valore del componente per il campo.

Si noti che alcuni campi HTTP hanno valori con serializzazioni multiple valide che hanno semantica equivalente, come valori insensibili alle maiuscole che gli intermediari potrebbero modificare. Le applicazioni che firmano ed elaborano tali campi DEVONO considerare come gestire i valori di tali campi per garantire che firmatario e verificatore possano derivare lo stesso valore, come discusso nella Sezione 7.5.2.

Di seguito sono riportati esempi non normativi di valori di componente per campi di intestazione, dato il seguente frammento di messaggio HTTP di esempio:

Host: www.example.com Date: Tue, 20 Apr 2021 02:07:56 GMT X-OWS-Header: Leading and trailing whitespace. X-Obs-Fold-Header: Obsolete line folding. Cache-Control: max-age=60 Cache-Control: must-revalidate Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)

L'esempio seguente mostra i valori di componente per questi campi di intestazione di esempio, presentati nel formato della base della firma definito nella Sezione 2.5:

"host": www.example.com "date": Tue, 20 Apr 2021 02:07:56 GMT "x-ows-header": Leading and trailing whitespace. "x-obs-fold-header": Obsolete line folding. "cache-control": max-age=60, must-revalidate "example-dict": a=1, b=2;x=1;y=2, c=(a b c)

Anche i campi HTTP vuoti possono essere firmati quando presenti in un messaggio. Il valore canonicalizzato è la stringa vuota. Ciò significa che il seguente campo di intestazione vuoto, con (SP) che indica un singolo carattere di spazio finale prima del valore di campo vuoto:

X-Empty-Header:(SP)

è serializzato dall'algoritmo di generazione della base della firma (Sezione 2.5) con un valore di stringa vuota dopo i due punti e lo spazio aggiunti dopo l'identificatore di componente.

"x-empty-header":(SP)

Qualsiasi identificatore di componente di campo HTTP PUÒ avere i seguenti parametri in circostanze specifiche, ciascuno descritto in dettaglio nelle proprie sezioni:

sf Un flag Boolean che indica che il valore del componente è serializzato usando la codifica rigorosa del valore Structured Field (Sezione 2.1.1).

key Un parametro String usato per selezionare un singolo valore membro da un Dictionary Structured Field (Sezione 2.1.2).

bs Un flag Boolean che indica che i singoli valori di campo sono codificati usando strutture dati Byte Sequence prima di essere combinati nel valore del componente (Sezione 2.1.3).

req Un flag Boolean per risposte firmate che indica che il valore del componente è derivato dalla richiesta che ha innescato questo messaggio di risposta e non direttamente dal messaggio di risposta. Si noti che questo parametro può essere applicato anche a identificatori di componenti derivati che puntano alla richiesta (Sezione 2.4).

tr Un flag Boolean che indica che il valore di campo è preso dai trailer del messaggio come definito nella Sezione 6.5 di [HTTP]. Se questo flag è assente, il valore di campo è preso dai campi di intestazione del messaggio come definito nella Sezione 6.3 di [HTTP] (Sezione 2.1.4).

PIÙ parametri POSSONO essere specificati insieme, sebbene alcune combinazioni siano ridondanti o incompatibili. Ad esempio, la funzionalità del parametro sf è già coperta quando il parametro key è usato su un elemento Dictionary, poiché key richiede la serializzazione rigorosa del valore. Il parametro bs, che richiede i byte grezzi dei valori di campo dal messaggio, non è compatibile con l'uso dei parametri sf o key, che richiedono le strutture dati analizzate dei valori di campo dopo la combinazione.

Parametri aggiuntivi possono essere definiti nel registro "HTTP Signature Component Parameters" istituito nella Sezione 6.5.