5. Formato del payload del datagramma HTTP

5. Formato del payload del datagramma HTTP

Quando i datagrammi HTTP (vedere la Sezione 2 di [HTTP-DGRAM]) sono associati ai flussi di richiesta di proxying UDP, il campo HTTP Datagram Payload ha il formato definito nella Figura 7, utilizzando la notazione dalla Sezione 1.3 di [QUIC]. Si noti che quando i datagrammi HTTP sono codificati utilizzando frame QUIC DATAGRAM [QUIC-DGRAM], il campo Context ID definito di seguito segue direttamente il campo Quarter Stream ID, che si trova all'inizio del payload del frame QUIC DATAGRAM; vedere la Sezione 2.1 di [HTTP-DGRAM].

UDP Proxying HTTP Datagram Payload { Context ID (i), UDP Proxying Payload (..), }

            Figura 7: Formato datagramma HTTP proxying UDP

Context ID: Un intero a lunghezza variabile (vedere la Sezione 16 di [QUIC]) che contiene il valore del Context ID. Se viene ricevuto un datagramme HTTP/3 che trasporta un Context ID sconosciuto, il ricevitore DEVE scartare quel datagramma silenziosamente o bufferizzarlo temporaneamente (nell'ordine di un tempo di andata e ritorno) in attesa della registrazione del Context ID corrispondente. UDP Proxying Payload: Il payload del datagramma, la cui semantica dipende dal valore del campo precedente. Si noti che questo campo può essere vuoto.

I pacchetti UDP sono codificati utilizzando datagrammi HTTP con il campo Context ID impostato su zero. Quando il campo Context ID è impostato su zero, il campo UDP Proxying Payload contiene il payload non modificato di un pacchetto UDP (indicato come ottetti di dati in [UDP]).

In virtù della definizione dell'intestazione UDP [UDP], non è possibile codificare payload UDP più lunghi di 65527 byte. Pertanto, gli endpoint NON DEVONO inviare datagrammi HTTP con un campo UDP Proxying Payload più lungo di 65527 utilizzando Context ID zero. Un endpoint che riceve un datagramma HTTP utilizzando Context ID zero il cui campo UDP Proxying Payload è più lungo di 65527 DEVE interrompere il flusso corrispondente. Se un proxy UDP sa di poter inviare solo pacchetti UDP di una certa lunghezza a causa del suo MTU di collegamento sottostante, non ha altra scelta che scartare i datagrammi HTTP in arrivo utilizzando Context ID zero il cui campo UDP Proxying Payload è più lungo di tale limite. Se il datagramma HTTP scartato è stato trasportato da una capsula DATAGRAM, il ricevitore DOVREBBE scartare quella capsula senza bufferizzare il contenuto della capsula.

Se un proxy UDP riceve un datagramma HTTP prima di aver ricevuto la richiesta corrispondente, DEVE scartare quel datagramma HTTP silenziosamente o bufferizzarlo temporaneamente (nell'ordine di un tempo di andata e ritorno) in attesa della richiesta corrispondente.

Si noti che il buffering dei datagrammi (perché la richiesta non è stata ancora ricevuta o perché il Context ID non è ancora noto) consuma risorse. I ricevitori che bufferizzano i datagrammi DOVREBBERO applicare limiti di buffering al fine di ridurre il rischio che si verifichi l'esaurimento delle risorse. Ad esempio, i ricevitori possono limitare il numero totale di datagrammi bufferizzati o la dimensione cumulativa dei datagrammi bufferizzati su base per flusso, per contesto o per connessione.

Un client PUÒ iniziare ottimisticamente a inviare pacchetti UDP in datagrammi HTTP prima di ricevere la risposta alla sua richiesta di proxying UDP. Tuttavia, gli implementatori dovrebbero notare che tali pacchetti proxyati potrebbero non essere elaborati dal proxy UDP se risponde alla richiesta con un fallimento o se i pacchetti proxyati vengono ricevuti dal proxy UDP prima della richiesta e il proxy UDP sceglie di non bufferizzarli.