Summary

  • RFC 9110 makes Via an ordered record of HTTP proxies and gateways that forwarded a particular message; its entries can use pseudonyms and, under narrow conditions, be combined.
  • A complete path claim needs the exact request and response fields joined to ingress and egress logs, configuration, tunnels, lower-layer routing, transformations and timing.

Imagine an incident review in which a request arrives with two Via members. The dashboard converts those two entries into a path diagram and declares that only two intermediaries handled the transaction. The diagram looks precise. It is also wrong. A firewall portal replaced internal names with a pseudonym, two gateways under one operator combined their same-protocol entries, a tunnel carried bytes without remaining an HTTP participant, and a lower-layer redirect never appeared in the field.

This is a hypothetical case, not a report about a named provider. It illustrates a common evidence error: interpreting a protocol field outside the scope of the protocol actors and disclosure rules that produced it.

RFC 9110 defines three common HTTP intermediary roles. A proxy is chosen by a client and forwards messages. A gateway acts as an origin server on its outward-facing side while translating or forwarding traffic inward. A tunnel becomes a blind relay between two connections and, once active, is no longer considered a party to the HTTP communication. The standard also notes that lower-layer devices can filter or redirect HTTP traffic without the knowledge or permission of HTTP senders. Those actors are indistinguishable from an on-path attacker at the protocol level; they do not gain a Via entry merely because they influenced the route.

The Via field has a narrower and useful purpose. On a request, it indicates intermediate protocols and recipients between user agent and server. On a response, it indicates them between origin server and client. Each member represents a proxy or gateway that forwarded that message. Within each member, received-protocol records the protocol version used by the upstream sender, while received-by identifies the recipient, subject to pseudonymization. The resulting list is ordered by forwarding recipients. That supports loop avoidance, troubleshooting and visibility into upstream protocol capabilities.

The protocol duties are asymmetric in ways that matter during an investigation. A single intermediary can change roles from one request to another. While it is acting as a proxy, it must send an appropriate Via field in every message it forwards. While it is acting as an HTTP-to-HTTP gateway rather than as an active tunnel, it must add one to inbound request messages, but only may add one to forwarded responses. Once it switches into active tunnel behavior, it is no longer a party to the HTTP communication. A response list is therefore not automatically a mirror of the request list. Comparing counts without direction, message identity, current role and capture point can manufacture symmetry that the standard does not promise.

Names are not stable identities either. The received-by value is normally a host and optional port, but a sender may replace a sensitive host with a pseudonym. A portal at a firewall boundary should avoid exposing internal host names unless explicitly configured to do so. Comments that might identify software are optional and can be removed before forwarding. Because Via is not authenticated, a token is an asserted forwarding record; only trusted capture and integrity evidence can support a claim of participation. The token cannot by itself establish a routable address, one machine, one process or one legal operator.

Even list length needs interpretation. RFC 9110 permits an intermediary to combine an ordered subsequence only when its members share the same received-protocol value; the sender should still refrain unless those members are also under the same organizational control and their host values have already been replaced by pseudonyms. Members with different received protocols must not be combined. Read together, these constraints preserve protocol capability boundaries while allowing a controlled, pseudonymized internal topology to be compressed. One visible member may therefore summarize several forwarding recipients.

Transformations create a separate evidence plane. A proxy can modify fields or content while forwarding. A gateway can translate between HTTP and a private inbound protocol. A tunnel can carry encrypted bytes while revealing neither application messages nor the relays behind its endpoints. The Via value tells downstream recipients about participating HTTP forwards; it does not fully attribute content changes, cache decisions, security checks, load-balancer choices or physical links.

A defensible message-custody receipt should preserve the exact request and response identity, raw Via values at every available capture point, protocol version and direction, the mapping from pseudonym to controlled intermediary, every permitted combination policy, ingress and egress timestamps, cache and transformation decisions, tunnel endpoints, and lower-layer observations. It should distinguish “not visible in Via” from “not present on the path.” This receipt is an editorial operating synthesis, not a wire object defined by the IETF.

That distinction keeps this commission separate from adjacent work. Temporary IPv6 addresses concern correlation after interface-identifier rotation. BFD concerns scoped liveness and route or forwarding decisions. HTTP Priority concerns whether a scheduling preference changed delivery. Via instead concerns the provenance and completeness of a message-forwarding record.

Sources