Security Must Follow the Request, Not the Shortcut
The subject of this series is the security of HTTP/3-to-HTTP/1.1 translation in CDN infrastructure, and the final question is what must remain authoritative when transport, caching, routing, and compatibility shortcuts meet independently implemented layers. This synthesis turns the H3Act measurements, RFC 9114's protocol rules, and the related connection-routing analysis into an operating model: readers can judge a deployment by following request meaning through every boundary, then choose controls and regression tests without treating HTTP/3 itself as the problem.
The answer is not to reject performance. QUIC's multiplexing, flow control, and connection behavior solve real delivery problems. CDNs use HTTP/3 at the edge because those improvements matter to users and operators. The answer is also not to trust a protocol label as a security guarantee. A CDN can accept a correctly authenticated HTTP/3 request and still forward the wrong authority, the wrong amount of work, an invalid value, or a request on the wrong backend. Security is preserved only when the request's meaning survives the path that actually processes it.
One rule, several failure surfaces
The most useful rule is simple: the effective request must remain authoritative at the point where a decision is made. “Effective” means the authority, path, fields, body, conditions, and framing that the receiving component is supposed to use for this request. “Authoritative” means that an earlier connection choice, a convenient normalization, or a cache-side assumption cannot silently replace that request-specific meaning.
This rule explains why the failure families in H3Act belong together without being the same bug. A Range or conditional-request failure lets a small client instruction become larger origin work. A slow-request failure lets client timing control resources that the edge has already committed upstream. A cache-poisoning failure lets one identity label a response while another identity selects the backend. A CRLF or meta-character failure lets a field become a message boundary in a downstream parser. Connection contamination lets a connection-level route override the authority on a later request. The shared error is stale or split meaning; the affected state and consequence differ.
The rule also clarifies what HTTP/3 changes and what it does not. RFC 9114 defines a mapping of HTTP semantics over QUIC. It gives requests independent streams, carries fields in HEADERS frames and content in DATA frames, and requires strict handling of malformed messages. Those choices improve transport and provide a clear source-side contract. They do not guarantee that a CDN's translator, cache, router, or HTTP/1.1 origin parser will apply the same interpretation after the boundary.
A useful way to reason about a request is to ask four questions in order. What did the client intend? What did the edge accept, transform, or reuse? What did the origin or cache actually receive and store? What additional conditions are needed before the result becomes a security impact? The first question is about semantics. The second is about the implementation path. The third is about observable effect. The fourth is about deployment-specific consequence. Skipping a question is how an anomaly becomes an exaggerated claim.
H3Act's method is valuable because it measures the middle two questions together. Its Generator creates protocol-valid HTTP/3 cases from protocol rules and security principles. Its Analyzer compares the cases with client-side and origin-side records. The controlled origin exposes the HTTP/1.1 representation that the CDN created, while human review tests whether the alleged difference is real. This approach does not make the model infallible; it makes the hidden conversion behavior available for inspection without requiring the CDN's source code.
The distinction between a protocol rule and an implementation observation must remain visible. RFC 9114 says that an intermediary must not forward malformed messages, that invalid field values must be rejected, and that an HTTP/3 intermediary must map :authority to Host when necessary. H3Act reports that particular tested CDN paths did not always preserve related semantics. The rule is general; the observed failure is bounded to the tested service, configuration, request, and downstream behavior.
The same distinction applies to connection reuse. HTTP/3 permits a client to reuse a connection for another URI authority when the certificate is valid for that origin. That is a performance feature. The related Internet-Draft describes a risk only when the certificate and listener span isolated origins, the client coalesces the connection, and the routing layer relies on stale connection-scoped state instead of checking the current :authority.