3. Starting HTTP/2 (Avvio di HTTP/2)

Le implementazioni che generano richieste HTTP devono scoprire se un server supporta HTTP/2.

HTTP/2 utilizza gli schemi URI "http" e "https" definiti nella sezione 4.2 di [HTTP], con gli stessi numeri di porta predefiniti di HTTP/1.1 [HTTP/1.1]. Questi URI non includono alcuna indicazione su quali versioni HTTP un server upstream (il peer immediato con cui il client desidera stabilire una connessione) supporta.

I mezzi con cui viene determinato il supporto per HTTP/2 sono diversi per gli URI "http" e "https". La scoperta per gli URI "https" è descritta nella sezione 3.2. Il supporto HTTP/2 per gli URI "http" può essere scoperto solo tramite mezzi fuori banda (Out-of-Band Means) e richiede una conoscenza preliminare (Prior Knowledge) del supporto come descritto nella sezione 3.3.

3.1. HTTP/2 Version Identification (Identificazione della versione HTTP/2)

Il protocollo definito in questo documento ha due identificatori. La creazione di una connessione basata su uno dei due implica l'uso del trasporto, del framing e della semantica dei messaggi descritti in questo documento.

• La stringa "h2" identifica il protocollo in cui HTTP/2 utilizza Transport Layer Security (TLS); vedere la sezione 9.2. Questo identificatore viene utilizzato nel campo dell'estensione Application-Layer Protocol Negotiation (ALPN) di TLS [TLS-ALPN] e in qualsiasi luogo in cui viene identificato HTTP/2 su TLS.

  La stringa "h2" viene serializzata in un identificatore di protocollo ALPN come sequenza di due ottetti: 0x68, 0x32.

• La stringa "h2c" è stata precedentemente utilizzata come token per il campo di intestazione Upgrade del meccanismo di aggiornamento HTTP (sezione 7.8 di [HTTP]). Questo utilizzo non è mai stato ampiamente distribuito ed è deprecato da questo documento. Lo stesso vale per il campo di intestazione HTTP2-Settings, che veniva utilizzato con l'aggiornamento a "h2c".

3.2. Starting HTTP/2 for "https" URIs (Avvio di HTTP/2 per URI "https")

Un client che effettua una richiesta a un URI "https" utilizza TLS [TLS13] con l'estensione ALPN [TLS-ALPN].

HTTP/2 su TLS utilizza l'identificatore di protocollo "h2". L'identificatore di protocollo "h2c" non deve (MUST NOT) essere inviato da un client o selezionato da un server; l'identificatore di protocollo "h2c" descrive un protocollo che non utilizza TLS.

Una volta completata la negoziazione TLS, sia il client che il server devono (MUST) inviare una prefazione di connessione (Connection Preface, sezione 3.4).

3.3. Starting HTTP/2 with Prior Knowledge (Avvio di HTTP/2 con conoscenza preliminare)

Un client può apprendere che un determinato server supporta HTTP/2 tramite altri mezzi. Ad esempio, un client potrebbe essere configurato con la conoscenza che un server supporta HTTP/2.

Un client che sa che un server supporta HTTP/2 può stabilire una connessione TCP e inviare la prefazione di connessione (sezione 3.4) seguita da frame HTTP/2. I server possono identificare queste connessioni dalla presenza della prefazione di connessione. Ciò influisce solo sulla creazione di connessioni HTTP/2 su TCP in chiaro; le connessioni HTTP/2 su TLS devono (MUST) utilizzare la negoziazione del protocollo in TLS [TLS-ALPN].

Allo stesso modo, il server deve (MUST) inviare una prefazione di connessione (sezione 3.4).

Senza informazioni aggiuntive, il supporto precedente per HTTP/2 non è un segnale forte che un determinato server supporterà HTTP/2 per connessioni future. Ad esempio, è possibile che le configurazioni del server cambino, che le configurazioni differiscano tra istanze in server in cluster o che le condizioni di rete cambino.

3.4. HTTP/2 Connection Preface (Prefazione di connessione HTTP/2)

In HTTP/2, ogni endpoint è tenuto a inviare una prefazione di connessione (Connection Preface) come conferma finale del protocollo in uso e per stabilire le impostazioni iniziali per la connessione HTTP/2. Il client e il server inviano ciascuno una prefazione di connessione diversa.

La prefazione di connessione client inizia con una sequenza di 24 ottetti, che in notazione esadecimale è:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

Cioè, la prefazione di connessione inizia con la stringa "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n". Questa sequenza deve (MUST) essere seguita da un frame SETTINGS (sezione 6.5), che può (MAY) essere vuoto. Il client invia la prefazione di connessione client come primi ottetti di dati dell'applicazione di una connessione.

Nota: La prefazione di connessione client è selezionata in modo che una grande proporzione di server e intermediari HTTP/1.1 o HTTP/1.0 non tenti di elaborare ulteriori frame. Si noti che questo non affronta le preoccupazioni sollevate in [TALKING].

La prefazione di connessione server consiste in un frame SETTINGS potenzialmente vuoto (sezione 6.5) che deve (MUST) essere il primo frame che il server invia nella connessione HTTP/2.

I frame SETTINGS ricevuti da un peer come parte della prefazione di connessione devono (MUST) essere riconosciuti (vedere sezione 6.5.3) dopo l'invio della prefazione di connessione.

Per evitare latenza non necessaria, ai client è permesso inviare frame aggiuntivi al server immediatamente dopo l'invio della prefazione di connessione client, senza attendere di ricevere la prefazione di connessione server. È importante notare, tuttavia, che il frame SETTINGS della prefazione di connessione server potrebbe includere impostazioni che necessariamente alterano il modo in cui un client deve comunicare con il server. Alla ricezione del frame SETTINGS, il client deve rispettare tutte le impostazioni stabilite. In alcune configurazioni, è possibile per il server trasmettere SETTINGS prima che il client invii frame aggiuntivi, fornendo un'opportunità per evitare questo problema.

I client e i server devono (MUST) trattare una prefazione di connessione non valida come un errore di connessione (sezione 5.4.1) di tipo PROTOCOL_ERROR. Un frame GOAWAY (sezione 6.8) può (MAY) essere omesso in questo caso, poiché una prefazione non valida indica che il peer non sta utilizzando HTTP/2.

---