3. Connection Setup and Management (Configurazione e gestione della connessione)
3.1. Discovering an HTTP/3 Endpoint (Scoperta di un endpoint HTTP/3)
HTTP si basa sulla nozione di risposta autoritativa (Authoritative Response): una risposta che è stata determinata essere la risposta più appropriata per quella richiesta, dato lo stato della risorsa di destinazione al momento dell'origine del messaggio di risposta da parte (o su indicazione) del server di origine (Origin Server) identificato nell'URI di destinazione. La localizzazione di un server autoritativo per un URI HTTP è discussa nella sezione 4.3 di [HTTP].
Lo schema "https" associa l'autorità al possesso di un certificato che il client considera affidabile per l'host identificato dal componente di autorità (Authority Component) dell'URI. Alla ricezione di un certificato del server nell'handshake TLS, il client deve (MUST) verificare che il certificato sia una corrispondenza accettabile per il server di origine dell'URI utilizzando il processo descritto nella sezione 4.3.4 di [HTTP]. Se il certificato non può essere verificato rispetto al server di origine dell'URI, il client non deve (MUST NOT) considerare il server autoritativo per quell'origine.
Un client può (MAY) tentare l'accesso a una risorsa con un URI "https" risolvendo l'identificatore dell'host in un indirizzo IP, stabilendo una connessione QUIC a quell'indirizzo sulla porta indicata (inclusa la validazione del certificato del server come descritto sopra) e inviando un messaggio di richiesta HTTP/3 che punta all'URI al server su quella connessione sicura. A meno che non venga utilizzato qualche altro meccanismo per selezionare HTTP/3, il token "h3" viene utilizzato nell'estensione ALPN (Application-Layer Protocol Negotiation; vedere [RFC7301]) durante l'handshake TLS.
Problemi di connettività (ad esempio, blocco UDP) possono comportare un fallimento nello stabilire una connessione QUIC; i client dovrebbero (SHOULD) tentare di utilizzare versioni basate su TCP di HTTP in questo caso.
I server possono (MAY) servire HTTP/3 su qualsiasi porta UDP; un annuncio di servizio alternativo (Alternative Service Advertisement) include sempre una porta esplicita, e gli URI contengono una porta esplicita o una porta predefinita associata allo schema.
3.1.1. HTTP Alternative Services (Servizi alternativi HTTP)
Un'origine HTTP può annunciare la disponibilità di un endpoint HTTP/3 equivalente tramite il campo di intestazione della risposta HTTP Alt-Svc o il frame HTTP/2 ALTSVC ([ALTSVC]) utilizzando il token ALPN "h3".
Ad esempio, un'origine potrebbe indicare in una risposta HTTP che HTTP/3 era disponibile sulla porta UDP 50781 allo stesso nome host includendo il seguente campo di intestazione:
Alt-Svc: h3=":50781"
Alla ricezione di un record Alt-Svc che indica il supporto HTTP/3, un client può (MAY) tentare di stabilire una connessione QUIC all'host e alla porta indicati; se questa connessione ha successo, il client può inviare richieste HTTP utilizzando la mappatura descritta in questo documento.
3.1.2. Other Schemes (Altri schemi)
Sebbene HTTP sia indipendente dal protocollo di trasporto, lo schema "http" associa l'autorità con la capacità di ricevere connessioni TCP sulla porta indicata di qualsiasi host identificato all'interno del componente di autorità. Poiché HTTP/3 non utilizza TCP, HTTP/3 non può essere utilizzato per l'accesso diretto al server autoritativo per una risorsa identificata da un URI "http". Tuttavia, estensioni di protocollo come [ALTSVC] permettono al server autoritativo di identificare altri servizi che sono anche autoritativi e che potrebbero essere raggiungibili tramite HTTP/3.
Prima di effettuare richieste per un'origine il cui schema non è "https", il client deve (MUST) assicurarsi che il server sia disposto a servire quello schema. Per le origini il cui schema è "http", un metodo sperimentale per raggiungere questo obiettivo è descritto in [RFC8164]. Altri meccanismi potrebbero essere definiti per vari schemi in futuro.
3.2. Connection Establishment (Stabilimento della connessione)
HTTP/3 si basa su QUIC versione 1 come trasporto sottostante. L'uso di altre versioni di trasporto QUIC con HTTP/3 può (MAY) essere definito da specifiche future.
QUIC versione 1 utilizza TLS versione 1.3 o superiore come protocollo di handshake (Handshake Protocol). I client HTTP/3 devono (MUST) supportare un meccanismo per indicare l'host di destinazione al server durante l'handshake TLS. Se il server è identificato da un nome di dominio ([DNS-TERMS]), i client devono (MUST) inviare l'estensione TLS Server Name Indication (SNI; [RFC6066]) a meno che non venga utilizzato un meccanismo alternativo per indicare l'host di destinazione.
Le connessioni QUIC vengono stabilite come descritto in [QUIC-TRANSPORT]. Durante lo stabilimento della connessione, il supporto HTTP/3 è indicato selezionando il token ALPN "h3" nell'handshake TLS. Il supporto per altri protocolli a livello di applicazione può (MAY) essere offerto nello stesso handshake.
Mentre le opzioni a livello di connessione relative al protocollo QUIC principale vengono impostate nell'handshake crittografico iniziale, le impostazioni specifiche di HTTP/3 vengono trasmesse nel frame SETTINGS. Dopo che la connessione QUIC è stata stabilita, un frame SETTINGS deve (MUST) essere inviato da ciascun endpoint come frame iniziale del rispettivo flusso di controllo HTTP (HTTP Control Stream).
3.3. Connection Reuse (Riutilizzo della connessione)
Le connessioni HTTP/3 sono persistenti attraverso più richieste. Per le migliori prestazioni, ci si aspetta che i client non chiudano le connessioni fino a quando non viene determinato che non è necessaria ulteriore comunicazione con un server (ad esempio, quando un utente si allontana da una particolare pagina web) o fino a quando il server chiude la connessione.
Una volta che esiste una connessione a un endpoint del server, questa connessione può (MAY) essere riutilizzata per richieste con più componenti di autorità URI diversi. Per utilizzare una connessione esistente per una nuova origine, i client devono (MUST) validare il certificato presentato dal server per il nuovo server di origine utilizzando il processo descritto nella sezione 4.3.4 di [HTTP]. Ciò implica che i client dovranno conservare il certificato del server e qualsiasi informazione aggiuntiva necessaria per verificare quel certificato; i client che non lo fanno non saranno in grado di riutilizzare la connessione per origini aggiuntive.
Se il certificato non è accettabile rispetto alla nuova origine per qualsiasi motivo, la connessione non deve (MUST NOT) essere riutilizzata e dovrebbe (SHOULD) essere stabilita una nuova connessione per la nuova origine. Se il motivo per cui il certificato non può essere verificato potrebbe applicarsi ad altre origini già associate alla connessione, il client dovrebbe (SHOULD) rivalidare il certificato del server per quelle origini. Ad esempio, se la validazione di un certificato fallisce perché il certificato è scaduto o è stato revocato, questo potrebbe essere utilizzato per invalidare tutte le altre origini per le quali quel certificato è stato utilizzato per stabilire l'autorità.
I client non dovrebbero (SHOULD NOT) aprire più di una connessione HTTP/3 a un determinato indirizzo IP e porta UDP, dove l'indirizzo IP e la porta potrebbero essere derivati da un URI, un servizio alternativo selezionato ([ALTSVC]), un proxy configurato o la risoluzione del nome di uno qualsiasi di questi. Un client può (MAY) aprire più connessioni HTTP/3 allo stesso indirizzo IP e porta UDP utilizzando diverse configurazioni di trasporto o TLS ma dovrebbe (SHOULD) evitare di creare più connessioni con la stessa configurazione.
I server sono incoraggiati a mantenere aperte le connessioni HTTP/3 il più a lungo possibile ma sono autorizzati a terminare le connessioni inattive (Idle Connections) se necessario. Quando uno dei due endpoint sceglie di chiudere la connessione HTTP/3, l'endpoint che termina dovrebbe (SHOULD) prima inviare un frame GOAWAY (sezione 5.2) in modo che entrambi gli endpoint possano determinare in modo affidabile se i frame precedentemente inviati sono stati elaborati e completare o terminare con grazia qualsiasi attività rimanente necessaria.
Un server che non desidera che i client riutilizzino le connessioni HTTP/3 per una particolare origine può indicare che non è autoritativo per una richiesta inviando un codice di stato 421 (Misdirected Request, Richiesta indirizzata erroneamente) in risposta alla richiesta; vedere sezione 7.4 di [HTTP].