2. Il frame ORIGIN HTTP/2 (The ORIGIN HTTP/2 Frame)

Questo documento definisce un nuovo tipo di frame HTTP/2 ([RFC7540], Sezione 4) chiamato ORIGIN, che consente a un server di indicare quale/i origine/i [RFC6454] il server vorrebbe che il client considerasse come membri del Set di Origini (Sezione 2.3) per la connessione all'interno della quale si verifica.

2.1. Sintassi

Il tipo di frame ORIGIN è 0xc (decimale 12) e contiene zero o più istanze del campo Origin-Entry.

+-------------------------------+-------------------------------+
|         Origin-Entry (*)                                    ...
+-------------------------------+-------------------------------+

Un Origin-Entry è una stringa delimitata dalla lunghezza:

+-------------------------------+-------------------------------+
|         Origin-Len (16)       | ASCII-Origin?               ...
+-------------------------------+-------------------------------+

Specificamente:

Origin-Len: Un intero senza segno a 16 bit che indica la lunghezza, in ottetti, del campo ASCII-Origin.

Origin: Una sequenza OPZIONALE di caratteri contenente la serializzazione ASCII di un'origine ([RFC6454], Sezione 6.2) per la quale il mittente afferma che questa connessione è o potrebbe essere autorevole.

Il frame ORIGIN non definisce alcun flag. Tuttavia, futuri aggiornamenti a questa specifica POSSONO definire flag. Vedere Sezione 2.2.

2.2. Elaborazione dei frame ORIGIN

Il frame ORIGIN è un'estensione non critica di HTTP/2. Gli endpoint che non supportano questo frame possono ignorarlo tranquillamente al ricevimento.

Quando ricevuto da un client che implementa la specifica, viene utilizzato per inizializzare e manipolare il Set di Origini (vedere Sezione 2.3), modificando così il modo in cui il client stabilisce l'autorità per i server di origine (vedere Sezione 2.4).

Il frame ORIGIN DEVE essere inviato sullo stream 0; un frame ORIGIN su qualsiasi altro stream non è valido e DEVE essere ignorato.

Allo stesso modo, il frame ORIGIN è valido solo su connessioni con l'identificatore di protocollo "h2" o quando specificamente nominato dalla definizione del protocollo; DEVE essere ignorato quando ricevuto su una connessione con l'identificatore di protocollo "h2c".

Questa specifica non definisce alcun flag per il frame ORIGIN, ma futuri aggiornamenti a questa specifica (attraverso il consenso IETF) potrebbero utilizzarli per cambiarne la semantica. I primi quattro flag (0x1, 0x2, 0x4 e 0x8) sono riservati per modifiche non retrocompatibili; pertanto, quando uno di essi è impostato, il frame ORIGIN che li contiene DEVE essere ignorato dai client conformi a questa specifica, a meno che la semantica del flag non sia compresa. I restanti flag sono riservati per modifiche retrocompatibili e non influenzano l'elaborazione da parte dei client conformi a questa specifica.

Il frame ORIGIN descrive una proprietà della connessione e quindi viene elaborato hop-by-hop. Un intermediario NON DEVE inoltrare i frame ORIGIN. I client configurati per utilizzare un proxy DEVONO ignorare qualsiasi frame ORIGIN ricevuto da esso.

Ogni campo ASCII-Origin nel payload del frame DEVE essere analizzato come una serializzazione ASCII di un'origine ([RFC6454], Sezione 6.2). Se l'analisi fallisce, il campo DEVE essere ignorato.

Si noti che il frame ORIGIN non supporta i nomi wildcard (ad esempio, "*.example.com") in Origin-Entry. Di conseguenza, l'invio di ORIGIN quando è in uso un certificato wildcard disabilita efficacemente qualsiasi origine non esplicitamente elencata nel/i frame ORIGIN (quando il client comprende ORIGIN).

Vedere l'Appendice A per un algoritmo illustrativo per l'elaborazione dei frame ORIGIN.

2.3. Il set di origini

L'insieme di origini (come da [RFC6454]) per cui una determinata connessione potrebbe essere utilizzata è noto in questa specifica come Set di Origini.

Per impostazione predefinita, il Set di Origini per una connessione non è inizializzato. Un Set di Origini non inizializzato significa che i client applicano le regole di unione dalla Sezione 9.1.1 di [RFC7540].

Quando un frame ORIGIN viene ricevuto per la prima volta ed elaborato con successo da un client, il Set di Origini della connessione è definito per contenere un'origine iniziale. L'origine iniziale è composta da:

• Schema: "https"
• Host: il valore inviato nella Server Name Indication (SNI) ([RFC6066], Sezione 3) convertito in minuscolo; se SNI non è presente, l'indirizzo remoto della connessione (cioè, l'indirizzo IP del server)
• Porta: la porta remota della connessione (cioè, la porta del server)

Il contenuto di quel frame ORIGIN (e dei successivi) consente al server di aggiungere incrementalmente nuove origini al Set di Origini, come descritto nella Sezione 2.2.

Il Set di Origini è anche influenzato dal codice di stato di risposta 421 (Misdirected Request), come definito in [RFC7540], Sezione 9.1.2. Al ricevimento di una risposta con questo codice di stato, i client che implementano la specifica DEVONO creare la serializzazione ASCII dell'origine della richiesta corrispondente (come da [RFC6454], Sezione 6.2) e rimuoverla dal Set di Origini della connessione, se presente.

Nota: Quando si invia un frame ORIGIN a una connessione inizializzata come servizio alternativo [RFC7838], il Set di Origini iniziale (Sezione 2.3) conterrà un'origine con lo schema e l'hostname appropriati (poiché la RFC 7838 specifica che l'hostname dell'origine sia inviato in SNI). Tuttavia, è possibile che la porta sia diversa da quella dell'origine prevista, poiché il Set di Origini iniziale è calcolato utilizzando la porta effettiva in uso, che può essere diversa per il servizio alternativo. In questo caso, l'origine prevista deve essere inviata esplicitamente nel frame ORIGIN.

Ad esempio, un client che effettua richieste per "https://example.com" viene indirizzato a un servizio alternativo a ("h2", "x.example.net", "8443"). Se questo servizio alternativo invia un frame ORIGIN, l'origine iniziale sarà "https://example.com:8443". Il client non sarà in grado di utilizzare il servizio alternativo per effettuare richieste per "https://example.com" a meno che tale origine non sia esplicitamente inclusa nel frame ORIGIN.

2.4. Autorità, Push e Coalescing con ORIGIN

La Sezione 10.1 di [RFC7540] utilizza sia il DNS che il certificato Transport Layer Security (TLS) presentato per stabilire il/i server di origine per cui una connessione è autorevole, proprio come fa HTTP/1.1 in [RFC7230].

Inoltre, la Sezione 9.1.1 di [RFC7540] consente esplicitamente che una connessione sia utilizzata per più di un server di origine, se è autorevole. Ciò influisce su quali risposte possono essere considerate autorevoli, sia per le risposte dirette alle richieste che per il server push (vedere [RFC7540], Sezione 8.2.2). Indirettamente, influisce anche su quali richieste verranno inviate su una connessione, poiché i client generalmente invieranno richieste solo su connessioni che ritengono essere autorevoli per l'origine in questione.

Una volta che un Set di Origini è stato inizializzato per una connessione, i client che implementano questa specifica lo utilizzano per aiutare a determinare per cosa la connessione è autorevole. Specificamente, tali client NON DEVONO considerare una connessione autorevole per un'origine non presente nel Set di Origini, e DOVREBBERO utilizzare la connessione per tutte le richieste a origini nel Set di Origini per le quali la connessione è autorevole, a meno che non ci siano motivi operativi per aprire una nuova connessione.

Si noti che affinché una connessione sia considerata autorevole per una determinata origine, il server è ancora tenuto ad autenticarsi con un certificato che superi i controlli appropriati; vedere la Sezione 9.1.1 di [RFC7540] per ulteriori informazioni. Ciò include la verifica che l'host corrisponda a un valore "dNSName" dal campo "subjectAltName" del certificato (utilizzando le regole definite in [RFC2818]; vedere anche [RFC5280], Sezione 4.2.1.6).

Inoltre, i client POSSONO evitare di consultare il DNS per stabilire l'autorità della connessione per nuove richieste a origini nel Set di Origini; tuttavia, coloro che lo fanno affrontano nuovi rischi, come spiegato nella Sezione 4.

Poiché ORIGIN può modificare l'insieme di origini per cui una connessione viene utilizzata nel tempo, è possibile che un client possa avere più di una connessione praticabile a un'origine aperta in qualsiasi momento. Quando ciò si verifica, i client NON DOVREBBERO emettere nuove richieste su qualsiasi connessione il cui Set di Origini è un sottoinsieme proprio del Set di Origini di un'altra connessione, e DOVREBBERO chiuderla una volta che tutte le richieste in sospeso sono soddisfatte.

Il Set di Origini non è influenzato da eventuali annunci di servizi alternativi [RFC7838] fatti dal server. La pubblicità di un servizio alternativo non influisce sul fatto che un server sia autorevole.