5. Format de charge utile de datagramme HTTP
- Format de charge utile de datagramme HTTP
Lorsque des datagrammes HTTP (voir la section 2 de [HTTP-DGRAM]) sont associés à des flux de requête de proxy UDP, le champ HTTP Datagram Payload a le format défini à la figure 7, en utilisant la notation de la section 1.3 de [QUIC]. Notez que lorsque les datagrammes HTTP sont encodés à l'aide de trames QUIC DATAGRAM [QUIC-DGRAM], le champ Context ID défini ci-dessous suit directement le champ Quarter Stream ID, qui se trouve au début de la charge utile de la trame QUIC DATAGRAM ; voir la section 2.1 de [HTTP-DGRAM].
UDP Proxying HTTP Datagram Payload { Context ID (i), UDP Proxying Payload (..), }
Figure 7 : Format de datagramme HTTP de proxy UDP
Context ID : Un entier de longueur variable (voir la section 16 de [QUIC]) qui contient la valeur du Context ID. Si un datagramme HTTP/3 transportant un Context ID inconnu est reçu, le destinataire DOIT soit abandonner ce datagramme silencieusement, soit le mettre en mémoire tampon temporairement (de l'ordre d'un temps d'aller-retour) en attendant l'enregistrement du Context ID correspondant. UDP Proxying Payload : La charge utile du datagramme, dont la sémantique dépend de la valeur du champ précédent. Notez que ce champ peut être vide.
Les paquets UDP sont encodés à l'aide de datagrammes HTTP avec le champ Context ID défini sur zéro. Lorsque le champ Context ID est défini sur zéro, le champ UDP Proxying Payload contient la charge utile non modifiée d'un paquet UDP (appelée octets de données dans [UDP]).
En vertu de la définition de l'en-tête UDP [UDP], il n'est pas possible d'encoder des charges utiles UDP de plus de 65527 octets. Par conséquent, les points de terminaison NE DOIVENT PAS envoyer de datagrammes HTTP avec un champ UDP Proxying Payload de plus de 65527 en utilisant le Context ID zéro. Un point de terminaison qui reçoit un datagramme HTTP utilisant le Context ID zéro dont le champ UDP Proxying Payload est supérieur à 65527 DOIT interrompre le flux correspondant. Si un proxy UDP sait qu'il ne peut envoyer que des paquets UDP d'une certaine longueur en raison de son MTU de liaison sous-jacent, il n'a d'autre choix que de rejeter les datagrammes HTTP entrants utilisant le Context ID zéro dont le champ UDP Proxying Payload est supérieur à cette limite. Si le datagramme HTTP rejeté a été transporté par une capsule DATAGRAM, le destinataire DEVRAIT rejeter cette capsule sans mettre en mémoire tampon le contenu de la capsule.
Si un proxy UDP reçoit un datagramme HTTP avant d'avoir reçu la demande correspondante, il DOIT soit abandonner ce datagramme HTTP silencieusement, soit le mettre en mémoire tampon temporairement (de l'ordre d'un temps d'aller-retour) en attendant la demande correspondante.
Notez que la mise en mémoire tampon des datagrammes (soit parce que la demande n'a pas encore été reçue, soit parce que le Context ID n'est pas encore connu) consomme des ressources. Les destinataires qui mettent en mémoire tampon des datagrammes DEVRAIENT appliquer des limites de mise en mémoire tampon afin de réduire le risque d'épuisement des ressources. Par exemple, les destinataires peuvent limiter le nombre total de datagrammes mis en mémoire tampon ou la taille cumulée des datagrammes mis en mémoire tampon par flux, par contexte ou par connexion.
Un client PEUT commencer de manière optimiste à envoyer des paquets UDP dans des datagrammes HTTP avant de recevoir la réponse à sa demande de proxy UDP. Cependant, les implémenteurs doivent noter que ces paquets relayés peuvent ne pas être traités par le proxy UDP s'il répond à la demande par un échec ou si les paquets relayés sont reçus par le proxy UDP avant la demande et que le proxy UDP choisit de ne pas les mettre en mémoire tampon.