5. Chiusura della connessione (Connection Closure)

Una volta stabilita, una connessione HTTP/3 può essere utilizzata per molte richieste e risposte nel tempo fino a quando la connessione viene chiusa. La chiusura della connessione può avvenire in diversi modi.

5.1. Connessioni inattive (Idle Connections)

Ogni endpoint QUIC dichiara un timeout di inattività (Idle Timeout) durante l'handshake. Se la connessione QUIC rimane inattiva (nessun pacchetto ricevuto) per più di questa durata, il peer assumerà che la connessione sia stata chiusa. Le implementazioni HTTP/3 dovranno aprire una nuova connessione HTTP/3 per nuove richieste se la connessione esistente è rimasta inattiva per più del timeout di inattività negoziato durante l'handshake QUIC, e DOVREBBERO (SHOULD) farlo se si avvicinano al timeout di inattività; vedere la sezione 10.1 di [QUIC-TRANSPORT].

Ci si aspetta che i client HTTP richiedano che il trasporto mantenga le connessioni aperte mentre ci sono risposte in sospeso per richieste o push del server, come descritto nella sezione 10.1.2 di [QUIC-TRANSPORT]. Se il client non si aspetta una risposta dal server, è preferibile consentire a una connessione inattiva di scadere piuttosto che spendere sforzi per mantenere una connessione che potrebbe non essere necessaria. Un gateway PUÒ (MAY) mantenere le connessioni in previsione della necessità piuttosto che sostenere il costo di latenza della creazione della connessione ai server. I server NON DOVREBBERO (SHOULD NOT) mantenere attivamente le connessioni aperte.

5.2. Arresto della connessione (Connection Shutdown)

Anche quando una connessione non è inattiva, entrambi gli endpoint possono decidere di interrompere l'utilizzo della connessione e avviare una chiusura della connessione graziosa (Graceful Connection Close). Gli endpoint avviano l'arresto grazioso di una connessione HTTP/3 inviando un frame GOAWAY. Il frame GOAWAY contiene un identificatore che indica al ricevitore l'intervallo di richieste o push che sono stati o potrebbero essere elaborati in questa connessione. Il server invia un ID di flusso bidirezionale avviato dal client; il client invia un ID push. Le richieste o i push con l'identificatore indicato o superiore vengono rifiutati (sezione 4.1.1) dal mittente del GOAWAY. Questo identificatore PUÒ (MAY) essere zero se non sono state elaborate richieste o push.

Le informazioni nel frame GOAWAY consentono a un client e a un server di concordare quali richieste o push sono stati accettati prima dell'arresto della connessione HTTP/3. All'invio di un frame GOAWAY, l'endpoint DOVREBBE (SHOULD) annullare esplicitamente (vedere le sezioni 4.1.1 e 7.2.3) qualsiasi richiesta o push che abbia identificatori maggiori o uguali a quello indicato, al fine di ripulire lo stato di trasporto per i flussi interessati. L'endpoint DOVREBBE (SHOULD) continuare a farlo man mano che arrivano più richieste o push.

Gli endpoint NON DEVONO (MUST NOT) avviare nuove richieste o promettere nuovi push sulla connessione dopo la ricezione di un frame GOAWAY dal peer. I client POSSONO (MAY) stabilire una nuova connessione per inviare richieste aggiuntive.

Alcune richieste o push potrebbero essere già in transito:

• Alla ricezione di un frame GOAWAY, se il client ha già inviato richieste con un ID di flusso maggiore o uguale all'identificatore contenuto nel frame GOAWAY, tali richieste non verranno elaborate. I client possono riprovare in modo sicuro le richieste non elaborate su una connessione HTTP diversa. Un client che non è in grado di riprovare le richieste perde tutte le richieste in transito quando il server chiude la connessione.

  Le richieste su ID di flusso inferiori all'ID di flusso in un frame GOAWAY dal server potrebbero essere state elaborate; il loro stato non può essere conosciuto fino a quando non viene ricevuta una risposta, il flusso viene reimpostato individualmente, viene ricevuto un altro GOAWAY con un ID di flusso inferiore a quello della richiesta in questione, o la connessione termina.

  I server POSSONO (MAY) rifiutare richieste individuali su flussi al di sotto dell'ID indicato se queste richieste non sono state elaborate.

• Se un server riceve un frame GOAWAY dopo aver promesso push con un ID push maggiore o uguale all'identificatore contenuto nel frame GOAWAY, quei push non verranno accettati.

I server DOVREBBERO (SHOULD) inviare un frame GOAWAY quando la chiusura di una connessione è nota in anticipo, anche se il preavviso è breve, in modo che il peer remoto possa sapere se una richiesta è stata parzialmente elaborata o meno. Ad esempio, se un client HTTP invia un POST nello stesso momento in cui un server chiude una connessione QUIC, il client non può sapere se il server ha iniziato a elaborare quella richiesta POST se il server non invia un frame GOAWAY per indicare su quali flussi potrebbe aver agito.

Un endpoint PUÒ (MAY) inviare più frame GOAWAY indicando identificatori diversi, ma l'identificatore in ciascun frame NON DEVE (MUST NOT) essere maggiore dell'identificatore in qualsiasi frame precedente, poiché i client potrebbero aver già riprovato richieste non elaborate su un'altra connessione HTTP. Ricevere un GOAWAY contenente un identificatore maggiore di quello ricevuto in precedenza DEVE (MUST) essere trattato come un errore di connessione di tipo H3_ID_ERROR.

Un endpoint che sta tentando di arrestare graziosamente una connessione può inviare un frame GOAWAY con un valore impostato sul valore massimo possibile (2^62-4 per i server, 2^62-1 per i client). Ciò garantisce che il peer interrompa la creazione di nuove richieste o push. Dopo aver concesso il tempo per l'arrivo di eventuali richieste o push in transito, l'endpoint può inviare un altro frame GOAWAY indicando quali richieste o push potrebbe accettare prima della fine della connessione. Ciò garantisce che una connessione possa essere chiusa in modo pulito senza perdere richieste.

Un client ha maggiore flessibilità nel valore che sceglie per il campo Push ID in un GOAWAY che invia. Un valore di 2^62-1 indica che il server può continuare a soddisfare i push che sono già stati promessi. Un valore più piccolo indica che il client rifiuterà i push con ID push maggiori o uguali a questo valore. Come il server, il client PUÒ (MAY) inviare frame GOAWAY successivi purché l'ID push specificato non sia maggiore di qualsiasi valore inviato in precedenza.

Anche quando un GOAWAY indica che una determinata richiesta o push non verrà elaborato o accettato alla ricezione, le risorse di trasporto sottostanti esistono ancora. L'endpoint che ha avviato queste richieste può annullarle per ripulire lo stato di trasporto.

Una volta che tutte le richieste e i push accettati sono stati elaborati, l'endpoint può consentire alla connessione di diventare inattiva, oppure PUÒ (MAY) avviare una chiusura immediata della connessione. Un endpoint che completa un arresto grazioso DOVREBBE (SHOULD) utilizzare il codice di errore H3_NO_ERROR durante la chiusura della connessione.

Se un client ha consumato tutti gli ID di flusso bidirezionali disponibili con le richieste, il server non ha bisogno di inviare un frame GOAWAY, poiché il client non è in grado di effettuare ulteriori richieste.

5.3. Chiusura immediata dell'applicazione (Immediate Application Closure)

Un'implementazione HTTP/3 può chiudere immediatamente la connessione QUIC in qualsiasi momento. Ciò comporta l'invio di un frame QUIC CONNECTION_CLOSE al peer indicando che il livello applicazione ha terminato la connessione. Il codice di errore dell'applicazione in questo frame indica al peer perché la connessione viene chiusa. Vedere la sezione 8 per i codici di errore che possono essere utilizzati durante la chiusura di una connessione in HTTP/3.

Prima di chiudere la connessione, PUÒ (MAY) essere inviato un frame GOAWAY per consentire al client di riprovare alcune richieste. Includere il frame GOAWAY nello stesso pacchetto del frame QUIC CONNECTION_CLOSE migliora le possibilità che il frame venga ricevuto dai client.

Se ci sono flussi aperti che non sono stati esplicitamente chiusi, vengono chiusi implicitamente quando la connessione viene chiusa; vedere la sezione 10.2 di [QUIC-TRANSPORT].

5.4. Chiusura del trasporto (Transport Closure)

Per vari motivi, il trasporto QUIC potrebbe indicare al livello applicazione che la connessione è terminata. Ciò potrebbe essere dovuto a una chiusura esplicita da parte del peer, a un errore a livello di trasporto o a un cambiamento nella topologia di rete che interrompe la connettività.

Se una connessione termina senza un frame GOAWAY, i client DEVONO (MUST) presumere che qualsiasi richiesta inviata, in tutto o in parte, possa essere stata elaborata.