Aller au contenu principal

4. Identifiants de contexte

  1. Identifiants de contexte

Le mécanisme de proxy UDP dans HTTP défini dans ce document permet aux extensions futures d'échanger des datagrammes HTTP qui transportent une sémantique différente des charges utiles UDP. Certaines de ces extensions peuvent augmenter les charges utiles UDP avec des données supplémentaires, tandis que d'autres peuvent échanger des données complètement séparées des charges utiles UDP. Pour ce faire, tous les datagrammes HTTP associés aux flux de requête de proxy UDP commencent par un champ Context ID ; voir la section 5.

Les Context IDs sont des entiers de 62 bits (0 à 2^62-1). Les Context IDs sont encodés sous forme d'entiers de longueur variable ; voir la section 16 de [QUIC]. La valeur de Context ID 0 est réservée aux charges utiles UDP, tandis que les valeurs non nulles sont allouées dynamiquement. Les Context IDs pairs non nuls sont alloués par le client, et les Context IDs impairs sont alloués par le proxy. L'espace de noms Context ID est lié à une requête HTTP donnée ; il est possible qu'un Context ID avec la même valeur numérique soit alloué simultanément dans des requêtes distinctes, potentiellement avec une sémantique différente. Les Context IDs NE DOIVENT PAS être réalloués dans un espace de noms HTTP donné mais PEUVENT être alloués dans n'importe quel ordre. Les restrictions d'allocation de Context ID à l'utilisation de Context IDs pairs et impairs existent afin d'éviter le besoin de synchronisation entre les points de terminaison. Cependant, une fois qu'un Context ID a été alloué, ces restrictions ne s'appliquent pas à l'utilisation du Context ID ; il peut être utilisé par n'importe quel client ou proxy UDP, indépendamment du point de terminaison qui l'a initialement alloué.

L'enregistrement est l'action par laquelle un point de terminaison informe son pair de la sémantique et du format d'un Context ID donné. Ce document ne définit pas comment l'enregistrement se produit. Les extensions futures PEUVENT utiliser des champs d'en-tête HTTP ou des capsules pour enregistrer des Context IDs. Selon la méthode utilisée, il est possible que des datagrammes soient reçus avec des Context IDs qui n'ont pas encore été enregistrés. Par exemple, cela peut être dû à une réorganisation du paquet contenant le datagramme et du paquet contenant le message d'enregistrement pendant la transmission.