When the Edge Turns a Small Request into a Large One

In H3Act's study of HTTP/3-to-HTTP/1.1 CDN translation, this chapter focuses on a particular kind of semantic drift: the edge changes how much work a request authorizes or how long that work is held. Range and conditional requests expose the size and condition of that obligation; slow requests and upstream streaming expose its timing. Understanding those differences lets readers distinguish origin-side amplification from a CDN outage and choose controls that match the failure.

A client request often contains a limit that is easy to overlook because it is expressed as ordinary HTTP metadata. A range limits which bytes are wanted. A conditional field can say that a representation need not be sent if a known condition holds. The request may therefore be small while carrying a strong instruction about the amount of work that should happen upstream. A translation layer that drops or enlarges that instruction can make the origin do far more than the client appears to request.

The same boundary can create cost through timing. An HTTP/3 client can send a request in pieces, and a CDN can choose whether to wait for the complete request before opening or maintaining an origin connection. If it commits upstream resources too early, a slow but incomplete request can occupy state for longer than the edge's designers intended. The fields may be valid; the resource lifecycle can still be unsafe.

When limits and conditions disappear

Range requests provide a clear baseline. A valid single range should be passed to the origin as that range. Multiple ranges may need to be merged, especially when they overlap, so the origin does not retrieve redundant fragments. A logically invalid range should be rejected rather than forwarded as if it were meaningful. These are not arbitrary preferences. They define the relationship between the client's requested representation and the work the CDN asks the origin to perform.

H3Act found that the tested CDNs did not all preserve that relationship. The paper groups their behavior into forwarding, expansion, removal, ignoring, and refusing. Some edges removed the Range field during translation; others expanded the requested region or handled multiple ranges in service-specific ways. Removal is the most direct route to amplification: the origin can receive a request for a larger representation even though the client asked for a narrow slice. Expansion can have a similar effect, although the amount of extra work depends on the implementation and resource.

The important observation is not merely that the forwarded header differed. It is the mismatch between the client's constraint and the origin's obligation. In the study's measurements, the client could receive a one-byte response while the origin sent hundreds of kilobytes, megabytes, or, for a tested object, 29,552,200 bytes. The exact disparity varied by service and request type. That makes “amplification” primarily an origin-bandwidth and origin-work issue in this context, not automatic proof that the CDN edge itself becomes unavailable.

There is a legitimate reason for a CDN to fetch more than the smallest client-visible fragment: it may be filling a cache, merging fragments, or choosing an internal chunk size. The security question is whether that extra work is bounded by a policy the customer and origin can expect, and whether the edge's response and cache behavior remain consistent with the request.