Résumé

  • Selon le RFC 9110, Via est une liste ordonnée des mandataires et passerelles HTTP qui ont relayé un message précis ; les entrées peuvent être pseudonymisées et parfois regroupées.
  • Pour affirmer qu’un chemin est complet, il faut relier les champs exacts de la requête et de la réponse aux journaux d’entrée et de sortie, aux tunnels, aux transformations, au réseau sous-jacent et aux horodatages.

Imaginons une revue d’incident où une requête contient deux membres Via. Le tableau de bord transforme ces deux entrées en schéma et conclut que la transaction n’a traversé que deux intermédiaires. Pourtant, un portail de pare-feu a masqué plusieurs noms internes derrière un pseudonyme, deux passerelles du même opérateur ont regroupé leurs entrées de même protocole, un tunnel a relayé les octets sans rester un participant HTTP, et une redirection de couche inférieure n’est jamais apparue dans le champ.

Ce scénario est hypothétique. Il ne décrit aucun fournisseur. Il met en lumière une erreur de preuve : donner à un champ protocolaire une portée supérieure à celle des acteurs et des règles de divulgation qui l’ont produit.

Le RFC 9110 distingue trois formes usuelles d’intermédiaires HTTP. Le mandataire est choisi par le client et relaie les messages. La passerelle se présente comme serveur d’origine vers l’extérieur puis traduit ou transfère le trafic vers l’intérieur. Le tunnel devient un relais aveugle entre deux connexions et, une fois actif, n’est plus considéré comme participant à la communication HTTP. Le texte signale aussi des équipements de couche inférieure capables de filtrer ou rediriger le trafic sans être visibles des émetteurs HTTP. Leur influence ne crée pas une entrée Via.

Le champ garde néanmoins une fonction précise. Dans une requête, il indique les protocoles et destinataires intermédiaires entre l’agent utilisateur et le serveur. Dans une réponse, il les indique entre le serveur d’origine et le client. Chaque membre représente un mandataire ou une passerelle ayant relayé le message. received-protocol consigne la version de protocole employée par l’émetteur en amont, tandis que received-by désigne le destinataire, éventuellement par un pseudonyme. L’ordre obtenu aide à repérer les boucles, à diagnostiquer un transfert et à connaître les capacités protocolaires annoncées en amont.

Les obligations diffèrent selon le rôle et le sens, et un même intermédiaire peut changer de rôle d’une requête à l’autre. Lorsqu’il agit comme mandataire, il doit ajouter un champ Via approprié à chaque message transféré. Lorsqu’il agit comme passerelle HTTP vers HTTP, et non comme tunnel actif, il doit le faire dans les requêtes entrantes, tandis que l’ajout aux réponses transférées reste facultatif. Dès qu’il fonctionne comme tunnel actif, il ne participe plus à la communication HTTP. La chaîne visible dans une réponse n’est donc pas nécessairement le miroir de celle de la requête. Comparer des nombres sans conserver le sens, l’identité du message, le rôle effectif et le point de capture crée une symétrie que la norme ne promet pas.

La valeur received-by n’est pas davantage un registre stable des machines. Elle contient normalement un hôte et éventuellement un port, mais peut être remplacée par un pseudonyme lorsque l’identité réelle est sensible. À la frontière d’un pare-feu, il est recommandé de ne pas divulguer les noms internes sans autorisation explicite. Les commentaires logiciels sont facultatifs et peuvent être supprimés. Via n’étant pas authentifié, une entrée constitue une déclaration de transfert ; seule une capture fiable assortie d’un contrôle d’intégrité peut étayer la participation. L’entrée ne suffit pas à identifier une adresse routable, un processus ou un exploitant.

La longueur de la liste demande elle aussi une interprétation. RFC 9110 n’autorise le regroupement d’une suite ordonnée que si ses membres ont le même received-protocol ; même dans ce cas, l’émetteur devrait s’en abstenir s’ils ne relèvent pas aussi de la même organisation ou si leurs hôtes n’ont pas déjà été remplacés par des pseudonymes. Les protocoles reçus différents ne peuvent pas être fusionnés. Pris ensemble, ces critères conservent la limite de capacité protocolaire tout en permettant de compresser une topologie interne contrôlée et pseudonymisée. Un membre visible peut donc résumer plusieurs relais.

Les transformations forment un autre plan de preuve. Un mandataire peut modifier des champs ou le contenu. Une passerelle peut traduire HTTP vers un protocole privé. Un tunnel transporte des octets chiffrés sans exposer les messages applicatifs ni tous les relais. Via décrit la participation au transfert HTTP ; il n’attribue pas complètement les changements de contenu, les décisions de cache, les contrôles de sécurité, l’équilibrage ou les liens physiques.

Un dossier de traçabilité du message doit conserver l’identité exacte de la requête et de la réponse, les valeurs Via brutes à chaque point de capture, le protocole et le sens, la correspondance entre pseudonyme et intermédiaire contrôlé, la règle de regroupement, les heures d’entrée et de sortie, le cache, les transformations, les extrémités de tunnel et les observations de couche inférieure. « Invisible dans Via » doit rester distinct de « absent du chemin ». Ce dossier est une synthèse opérationnelle éditoriale, non un objet de protocole de l’IETF.

Le sujet reste ainsi séparé des travaux voisins. Les adresses IPv6 temporaires portent sur la corrélation malgré la rotation d’identifiant. BFD porte sur une détection de disponibilité délimitée et les choix de route ou de transfert. HTTP Priority porte sur l’effet d’une préférence d’ordonnancement. Ici, la question est l’origine et l’exhaustivité de la trace de transfert d’un message.

Sources