2. Datagrammi HTTP (HTTP Datagrams)
I datagrammi HTTP (HTTP Datagrams) sono una convenzione per trasmettere datagrammi bidirezionali e potenzialmente inaffidabili all'interno di una connessione HTTP con multiplexing quando possibile. Tutti i datagrammi HTTP sono associati a una richiesta HTTP.
Quando i datagrammi HTTP vengono trasmessi su una connessione HTTP/3, il frame QUIC DATAGRAM può essere utilizzato per fornire demultiplexing e consegna inaffidabile; vedere la sezione 2.1. La negoziazione dell'uso dei frame QUIC DATAGRAM per i datagrammi HTTP viene ottenuta tramite lo scambio di impostazioni HTTP/3; vedere la sezione 2.1.1.
Quando viene eseguito su HTTP/2, il demultiplexing è fornito dal livello di framing HTTP/2, ma la consegna inaffidabile non è disponibile. I datagrammi HTTP vengono negoziati e trasmessi utilizzando il protocollo Capsule; vedere la sezione 3.5.
Quando viene eseguito su HTTP/1.x, le richieste sono strettamente serializzate nella connessione; pertanto, il demultiplexing non è disponibile. La consegna inaffidabile non è disponibile. I datagrammi HTTP vengono negoziati e trasmessi utilizzando il protocollo Capsule; vedere la sezione 3.5.
I datagrammi HTTP devono (MUST) essere inviati solo con un'associazione a una richiesta HTTP che li supporta esplicitamente. Ad esempio, i metodi HTTP esistenti GET e POST non definiscono semantica per i datagrammi HTTP associati; pertanto, i datagrammi HTTP associati ai flussi di richiesta GET o POST non possono essere inviati.
Se viene ricevuto un datagramma HTTP ed è associato a una richiesta che non ha semantica nota per i datagrammi HTTP, il ricevitore deve (MUST) terminare la richiesta. Se HTTP/3 è in uso, il flusso di richiesta deve (MUST) essere interrotto con H3_DATAGRAM_ERROR (0x33). Le estensioni HTTP possono (MAY) sovrascrivere questi requisiti definendo un meccanismo di negoziazione e una semantica per i datagrammi HTTP.
2.1. Datagrammi HTTP/3 (HTTP/3 Datagrams)
Quando utilizzato con HTTP/3, il campo Datagram Data dei frame QUIC DATAGRAM utilizza il seguente formato:
HTTP/3 Datagram {
Quarter Stream ID (i),
HTTP Datagram Payload (..),
}
Figura 1: Formato del datagramma HTTP/3
Quarter Stream ID: Un intero a lunghezza variabile che contiene il valore del flusso bidirezionale avviato dal client a cui questo datagramma è associato diviso per quattro (la divisione per quattro deriva dal fatto che le richieste HTTP vengono inviate su flussi bidirezionali avviati dal client, che hanno ID di flusso divisibili per quattro). Il valore massimo legale dell'ID di flusso QUIC è 2^62-1, quindi il valore massimo legale del campo Quarter Stream ID è 2^60-1. La ricezione di un datagramma HTTP/3 che include un valore maggiore deve (MUST) essere trattata come un errore di connessione HTTP/3 di tipo H3_DATAGRAM_ERROR (0x33).
HTTP Datagram Payload: Il payload del datagramma, la cui semantica è definita dall'estensione che utilizza i datagrammi HTTP. Si noti che questo campo può essere vuoto.
La ricezione di un frame QUIC DATAGRAM il cui payload è troppo corto per consentire l'analisi del campo Quarter Stream ID deve (MUST) essere trattata come un errore di connessione HTTP/3 di tipo H3_DATAGRAM_ERROR (0x33).
I datagrammi HTTP/3 non devono (MUST NOT) essere inviati a meno che il lato di invio del flusso corrispondente non sia aperto. Se un datagramma viene ricevuto dopo che il lato di ricezione del flusso corrispondente è chiuso, i datagrammi ricevuti devono (MUST) essere scartati silenziosamente.
Se viene ricevuto un datagramma HTTP/3 e il suo campo Quarter Stream ID corrisponde a un flusso che non è ancora stato creato, il ricevitore deve (SHALL) scartare quel datagramma silenziosamente o bufferizzarlo temporaneamente (nell'ordine di un round trip) in attesa della creazione del flusso corrispondente.
Se viene ricevuto un datagramma HTTP/3 e il suo campo Quarter Stream ID corrisponde a un flusso che non può essere creato a causa dei limiti di flusso bidirezionale avviati dal client, dovrebbe (SHOULD) essere trattato come un errore di connessione HTTP/3 di tipo H3_ID_ERROR. La generazione di un errore non è obbligatoria perché il limite di flusso QUIC potrebbe essere sconosciuto al livello HTTP/3.
La prioritizzazione dei datagrammi HTTP/3 non è definita in questo documento. Le estensioni future possono (MAY) definire come prioritizzare i datagrammi e possono (MAY) definire la segnalazione per consentire la comunicazione delle preferenze di prioritizzazione.
2.1.1. L'impostazione HTTP/3 SETTINGS_H3_DATAGRAM
Un endpoint può indicare al suo peer che è disposto a ricevere datagrammi HTTP/3 inviando l'impostazione SETTINGS_H3_DATAGRAM (0x33) con un valore di 1.
Il valore dell'impostazione SETTINGS_H3_DATAGRAM deve (MUST) essere 0 o 1. Un valore di 0 indica che l'implementazione non è disposta a ricevere datagrammi HTTP. Se l'impostazione SETTINGS_H3_DATAGRAM viene ricevuta con un valore che non è né 0 né 1, il ricevitore deve (MUST) terminare la connessione con l'errore H3_SETTINGS_ERROR.
I frame QUIC DATAGRAM non devono (MUST NOT) essere inviati fino a quando l'impostazione SETTINGS_H3_DATAGRAM non è stata sia inviata che ricevuta con un valore di 1.
Quando i client utilizzano 0-RTT, possono (MAY) memorizzare il valore dell'impostazione SETTINGS_H3_DATAGRAM del server. Ciò consente al client di inviare frame QUIC DATAGRAM in pacchetti 0-RTT. Quando i server decidono di accettare dati 0-RTT, devono (MUST) inviare un'impostazione SETTINGS_H3_DATAGRAM maggiore o uguale al valore che hanno inviato al client nella connessione in cui hanno inviato loro il messaggio NewSessionTicket. Se un client memorizza il valore dell'impostazione SETTINGS_H3_DATAGRAM con il suo stato 0-RTT, deve (MUST) validare che il nuovo valore dell'impostazione SETTINGS_H3_DATAGRAM inviato dal server nell'handshake sia maggiore o uguale al valore memorizzato; in caso contrario, il client deve (MUST) terminare la connessione con l'errore H3_SETTINGS_ERROR. In tutti i casi, il valore massimo consentito del parametro di impostazione SETTINGS_H3_DATAGRAM è 1.
Si raccomanda (RECOMMENDED) che le implementazioni che supportano la ricezione di datagrammi HTTP/3 inviino sempre l'impostazione SETTINGS_H3_DATAGRAM con un valore di 1, anche se l'applicazione non intende utilizzare i datagrammi HTTP/3. Questo aiuta a evitare di "distinguersi"; vedere la sezione 4.
2.2. Datagrammi HTTP che utilizzano Capsule (HTTP Datagrams Using Capsules)
Quando i datagrammi HTTP/3 non sono disponibili o non sono desiderabili, i datagrammi HTTP possono essere inviati utilizzando il protocollo Capsule; vedere la sezione 3.5.