The Fast Path Has a Translation Problem
This series examines the security of HTTP/3-to-HTTP/1.1 translation in content delivery networks, using the H3Act study as its central case. This opening focuses on the boundary between a fast HTTP/3 edge and an HTTP/1.1 origin: it explains why transport improvements do not automatically preserve request meaning, so readers can follow where older bugs return and how to judge the evidence.
HTTP/3 is often introduced as a cleaner route to faster web delivery. It uses QUIC rather than TCP, keeps requests on independent streams, and combines transport security with lower-latency connection setup. Those are real changes. But a browser's connection is only one part of a modern web request. A CDN still has to decide which cached object, backend, and origin-facing representation correspond to that request. If the edge accepts HTTP/3 while the origin still speaks HTTP/1.1, the request crosses a boundary where one implementation must reconstruct the meaning understood by another.
That boundary is the subject of H3Act: Automated Measuring Semantic Conversion Anomalies of HTTP/3-to-HTTP/1.1 Translation in CDNs. Peng and colleagues tested nine commercial CDN services across seven providers and reported seven attack vectors spanning amplification, cache poisoning, and request smuggling. Every tested service showed at least one vector under the study's conditions. The result is important, but it needs a precise reading. It is evidence about tested translation paths and configurations, not a verdict that HTTP/3 itself is unsafe or that every CDN behaves the same way.
A faster connection still ends at an older interface
The key distinction is between transport semantics and application semantics. QUIC gives HTTP/3 reliable, ordered delivery within each stream, flow control per stream, and multiplexing that avoids making one delayed transaction stall every other transaction. TLS 1.3 is part of the QUIC handshake. These features improve how messages travel; they do not decide what a request means to a cache or an origin.
HTTP/3 therefore retains familiar HTTP concepts while expressing them differently on the wire. A request uses a HEADERS frame and may use DATA frames. Fields such as :method, :scheme, :authority, and :path identify the operation and target. The origin-facing side may instead receive an HTTP/1.1 request line and fields, including a Host field. A translator has to map between those representations without changing the resource, authority, body, conditions, or message boundaries the client intended.
That mapping involves more than changing syntax. HTTP/3's fields arrive inside a stream whose delivery boundaries are maintained by QUIC; the HTTP/1.1 side receives a representation that its own parser, router, and cache will interpret. The edge must decide when the header section is complete, whether the declared body length matches the DATA frames, which fields are legal, and which connection-specific signals must stop at the boundary. A permissive choice may not change the response seen by the original client, yet it can change what the origin processes or what the cache stores. The transport owns delivery, the HTTP layer identifies the target, the cache associates a representation with an identity, and the origin performs application work. A shortcut is safe only when it keeps those responsibilities distinct.
That obligation is easy to underestimate because the high-level vocabulary looks familiar. HTTP/3 was designed with HTTP/2 in mind, and both preserve HTTP semantics. But similar semantics do not guarantee identical implementations. The CDN may have separate HTTP/2 and HTTP/3 stacks, separate serializers, and separate validation paths. A fix made in one path can be absent from another even when both paths eventually send HTTP/1.1 upstream.
This is what “old bugs return” means in the context of the study. The claim is not that a historical vulnerability travels magically through a protocol upgrade. The claim is that a security invariant—such as the request's true host, a body boundary, or a validation rule—can be reimplemented incorrectly at the new boundary. The visible feature survives. The protection that once accompanied it does not.
The request's journey through a CDN
A CDN makes this problem consequential because it sits between the client and the origin and performs several jobs at once. An edge node receives the client connection. It may answer from cache, select a route, or contact the origin on a cache miss or when a representation needs revalidation. The origin usually sees the CDN's forwarded request rather than the client's original wire format. The response then travels back through the edge, where caching and other policy may affect what later clients receive.
The central question is not simply whether the edge accepted the request. It is whether every decision along that path used the same request identity and constraints. A request can be valid as HTTP/3 yet become a different request when its fields are mapped into HTTP/1.1. A response can look small to the client while the origin sends much more data. A cache can key an object by one host while routing the fetch using another. A connection can be reused safely for one origin but incorrectly treated as permission to serve another.
The diagram's translation arrow is not a cosmetic compatibility step. It is where a stream-based, binary-framed request becomes a text-oriented HTTP/1.1 message that another parser, router, and cache may interpret. The edge also owns decisions about whether to forward at all, how much of a resource to request, and which backend should receive it. Those decisions can be correct only if the edge preserves the information that controls them.
RFC 9114 makes several of those controls explicit. An HTTP/3 client normally identifies the target authority with :authority; an intermediary converting the request to HTTP/1.1 must create Host from that value when necessary. The request's :path carries the path and query. HTTP/3 does not use Transfer-Encoding, and it treats invalid field names, invalid field values, contradictory pseudo-headers, and inconsistent content lengths as malformed. An intermediary that processes HTTP must not forward a malformed message.
These rules establish a useful mental model: the request has a semantic checksum. Its authority, path, fields, body length, and framing must remain consistent even though their encoding changes. If the translator drops a constraint or accepts a value that HTTP/3 says is invalid, the origin is no longer receiving the same request in a meaningful security sense. The failure may appear as excess work, a wrong cache entry, or a second request hidden inside the first.
What “old bugs” means at a new boundary
H3Act is designed to find such differences without access to a CDN's source code or coverage data. Its generator produces protocol-valid HTTP/3 cases from protocol specifications and previously documented attack principles. Its analyzer compares the cases and the client-side observations with the HTTP/1.1 requests and responses recorded at a controlled origin. Feedback from the analysis guides later cases. This matters because a black-box test needs two kinds of understanding: it must construct an input that passes enough validation to reach the interesting path, and it must recognize when the origin saw a materially different meaning.
The study's findings give the translation problem concrete shape without reducing it to a single defect. It reports anomalies involving the amount of work sent toward an origin, the identity used by shared caches and routes, and the boundaries recognized by downstream parsers. These are different failure surfaces, but each begins when a boundary changes or reuses request meaning in a way that the next component does not interpret consistently.
The danger is not the mere presence of an unusual field. It is the possibility that an edge, cache, router, translator, and origin will make different decisions about the same request. An identity mismatch can affect shared state; a framing mismatch can make a downstream parser see a different message. The detailed cases require their own evidence, which is why the study's categories must be connected to the exact translation path rather than treated as a generic list of HTTP problems.
The study also found differences between HTTP/2 and HTTP/3 behavior. Some issues seen in HTTP/3 were absent or mitigated in HTTP/2; some appeared more often in HTTP/2. The authors interpret the pattern as evidence that the protocol paths are independently implemented. That observation supports a practical conclusion: a protocol upgrade needs fresh semantic regression tests. It does not support the broader conclusion that HTTP/3 is categorically less secure than HTTP/2.
The evidence has to be read with the same discipline as the request path. RFC 9114 is the authority for HTTP/3's normative rules. H3Act is first-party empirical evidence for the services, cases, measurements, and disclosures in its study. Its reported behavior and vendor responses are bounded by its experimental design; some providers confirmed or patched behaviors, while others described particular effects as expected cache-fill behavior or a shared-responsibility issue. A separate Internet-Draft discussed later in this series proposes a related connection-routing threat, but a draft is not an adopted standard and should not be treated as proof of prevalence.
The practical lesson is narrower and stronger than a protocol verdict. HTTP/3 can improve delivery while its translation path reopens older classes of failure. To understand why, we first need to examine the contract that the edge is supposed to preserve: which authority names the resource, which fields constrain the request, and which framing rules prevent an older parser from finding a different message inside it. Security follows those meanings—not the label on the transport—and the next analysis begins there.