2.2. Derived Components (Componenti derivati)

Oltre ai campi HTTP, esistono diverse componenti derivabili dai control data, dal contesto della firma o da altri aspetti del messaggio firmato. Tali componenti derivate possono essere incluse nella base definendo nome, parametri possibili, target del messaggio e metodo di derivazione del valore.

I nomi delle componenti derivate DEVONO iniziare con il carattere @. Ciò li distingue dai nomi dei campi HTTP, che non possono contenere @ (Sezione 5.1 di [HTTP]). I processori DEVONO trattare i nomi derivati separatamente dai nomi di campo (Sezione 7.5.1).

Questa specifica definisce le seguenti componenti derivate:

@method — Metodo usato per una richiesta (Sezione 2.2.1).

@target-uri — URI target completo della richiesta (Sezione 2.2.2).

@authority — Authority dell'URI target (Sezione 2.2.3).

@scheme — Schema dell'URI target (Sezione 2.2.4).

@request-target — Request target (Sezione 2.2.5).

@path — Porzione di percorso assoluto dell'URI target (Sezione 2.2.6).

@query — Porzione di query dell'URI target (Sezione 2.2.7).

@query-param — Parametro di query analizzato e codificato (Sezione 2.2.8).

@status — Codice di stato della risposta (Sezione 2.2.9).

Altri nomi sono nel registro "HTTP Signature Derived Component Names" (Sezione 6.4).

I valori sono tratti dal contesto del messaggio di destinazione, inclusi control data e stato aggiuntivo del firmatario o verificatore. Firmando una risposta, il firmatario può includere componenti derivate dalla richiesta originaria con req (Sezione 2.4).

request: Valori derivati da e applicati a un messaggio di richiesta HTTP (Sezione 3.4 di [HTTP]). Se il messaggio di destinazione è una risposta, le componenti che puntano alla richiesta possono usare req (Sezione 2.4).

response: Valori derivati da e applicati a una risposta HTTP (Sezione 3.4 di [HTTP]).

request, response: Valori derivati da e applicati a richiesta o risposta.

Una definizione di componente derivata DEVE definire tutti i tipi di messaggio target a cui può applicarsi.

I valori delle componenti derivate DEVONO essere limitati a caratteri stampabili e spazi e NON DEVONO contenere newline. NON DEVONO iniziare o finire con spazi bianchi.

2.2.1. Metodo (@method)

@method si riferisce al metodo HTTP della richiesta. Il valore è il nome del metodo come stringa. Il nome è sensibile alle maiuscole ([HTTP], Sezione 9.1). I nomi standardizzati sono di solito maiuscoli [ASCII]; non si applica trasformazione di maiuscole.

Esempio:

POST /path?param=value HTTP/1.1
Host: www.example.com

Valore: POST. Riga base: "@method": POST

2.2.2. URI target (@target-uri)

@target-uri è l'URI target della richiesta ([HTTP], Sezione 7.1), assemblato da tutti i componenti URI disponibili, inclusa l'authority.

Esempio su HTTPS:

POST /path?param=value HTTP/1.1
Host: www.example.com

Valore: https://www.example.com/path?param=value

Riga: "@target-uri": https://www.example.com/path?param=value

2.2.3. Authority (@authority)

@authority è il componente authority dell'URI target ([HTTP], Sezione 7.2). In HTTP/1.1 di solito tramite Host, in HTTP/2/3 tramite pseudo-header :authority. È la stringa authority completa (host e opzionalmente porta). Il valore DEVE essere normalizzato ([HTTP], Sezione 4.2.3): hostname minuscolo, porta predefinita omessa.

Esempio:

POST /path?param=value HTTP/1.1
Host: www.example.com

www.example.com — "@authority": www.example.com

È RACCOMANDATO usare @authority invece di firmare direttamente Host (Sezione 7.2.4).

2.2.4. Schema (@scheme)

@scheme è lo schema dell'URL target, stringa minuscola ([HTTP], Sezione 4.2). Lo schema non è sensibile alle maiuscole ma DEVE essere normalizzato in minuscolo.

HTTP in chiaro:

POST /path?param=value HTTP/1.1
Host: www.example.com

Valore http — "@scheme": http

2.2.5. Request target (@request-target)

@request-target è il request target completo ([HTTP], Sezione 7.1). Per HTTP/1.1 equivale alla porzione request line; in altre versioni è più difficile costruirlo in modo affidabile. NON è RACCOMANDATO usarlo quando possono essere in uso versioni diverse da 1.1.

Form origin: percorso assoluto + query.

POST /path?param=value HTTP/1.1
Host: www.example.com

"/path?param=value" — "@request-target": /path?param=value

Proxy con forma assoluta:

GET https://www.example.com/path?param=value HTTP/1.1

Stesso valore nell'URI completo.

CONNECT authority-form:

CONNECT www.example.com:80 HTTP/1.1 con Host: www.example.com → www.example.com:80

OPTIONS asterisk-form: * — "@request-target": *

2.2.6. Percorso (@path)

@path è il percorso assoluto del target senza query e senza ? finale, normalizzato ([HTTP] 4.2.3): percorso vuoto → /. I componenti del percorso sono i valori prima della decodifica percent-encoded ([URI] 6.2.1).

GET /path?param=value HTTP/1.1
Host: www.example.com

"/path"

2.2.7. Query (@query)

@query è l'intera query normalizzata [URI], incluso il ? iniziale. Percent-encoded non decodificati ([URI] 6.2.1).

GET /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1
Host: www.example.com

?param=value&foo=bar&baz=bat%2Dman

Con ?queryString sola: ?queryString

Se la query assente, il valore è solo ? per indicare componente vuota: "@query": ?

2.2.8. Parametri di query (@query-param)

Se la query usa parametri form HTML (Sezione 5 di [HTMLURL], application/x-www-form-urlencoded), @query-param indirizza singoli parametri. I parametri DEVONO essere analizzati secondo la Sezione 5.1 di [HTMLURL], producendo coppie (nameString, valueString). Il parametro RICHIESTO name nell'identificatore contiene il nameString codificato come String. Il valore della componente è il valueString codificato di quel parametro. Più parametri nominati POSSONO essere inclusi; POSSONO comparire in qualsiasi ordine nell'elenco coperto.

Processo per name e valore:

Analizzare nameString o valueString (Sezione 5.1 [HTMLURL]) dopo decodifica percent-encoded.
Codificare con "percent-encode after encoding" (Sezione 5.2 [HTMLURL]) → stringa ASCII [ASCII].
Output della stringa ASCII.

Il valore non include ?, = o & di separazione. Valori vuoti: stringa vuota (alcune librerie eliminano valori vuoti).

Se un parametro nominato è coperto ma assente nella query, ciò DEVE causare errore nella generazione della base.

Esempio:

GET /path?param=value&foo=bar&baz=batman&qux= HTTP/1.1
Host: www.example.com

Valori di componente per i parametri nominati baz, qux e param:

baz: batman

qux: stringa vuota

param: value

Righe nella base (con (SP) = singolo spazio finale prima del valore vuoto):

"@query-param";name="baz": batman "@query-param";name="qux":(SP) "@query-param";name="param": value

Limitazioni: solo UTF-8 percent-escaped come in [HTMLURL] Sezione 5; istanze multiple dello stesso nome non sono supportate in modo affidabile sul campo — il parametro nominato NON DEVE essere incluso se il nome compare più volte. Se comune nell'applicazione, è RACCOMANDATO firmare l'intera query con @query (Sezione 2.2.7).

Esempio con newline e + (RFC 8792):

GET /parameters?var=this%20is%20a%20big%0Amultiline%20value&\
 bar=with+plus+whitespace&fa%C3%A7ade%22%3A%20=something HTTP/1.1
Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT

Valori codificati come nell'RFC. Senza codifica, stringhe con caratteri illegali per nomi/valori.

2.2.9. Codice di stato (@status)

@status è il codice di stato numerico a tre cifre ([HTTP], Sezione 15), solo intero senza testo descrittivo.

HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT

200 — "@status": 200

L'identificatore @status NON DEVE essere usato in un messaggio di richiesta.