Repository navigation
Cannot download files from GCP #961
Description
Version
h2 0.4.16 - 0.4.19 (latest version at time of writing)
Platform
Not platform specific
Summary
Downloading (gzipped - may be relevant) files from GCP (google cloud) fails for me with recent versions of h2 (via reqwest).
Affects all versions of h2 (0.4.16 - 0.4.19 ) since #935 landed. I think this limit may need to be raised or else made configurable in higher level libraries like reqwest.
Code Sample
Expected Behavior
File is downloaded
Actual Behavior
The file fail triggers the DOS protection and fails to download
Additional Context
The specific files that are failing for me are the summary_v2 files as listed here https://github.com/web-platform-tests/wpt.fyi/blob/main/api/README.md#testrun-entities. That wpt.fyi API is public with no auth, so you should be able to reproduce this easily if desired (You can visit a link like https://wpt.fyi/api/runs?product=chrome&product=safari)
The actual code I'm running is https://github.com/DioxusLabs/blitz-website which is also open source and will attempt the downloads at startup (cargo run). Issues should reproduce with commit cbb9288cf89845546fceba0e2af2af1624473572, after that I pin the HTTP version to 1.1 to workaround the issue.
Activity
seanmonstar commentedon Sep 27, 2026
Sorry about that! Do you have any more information that would help identify what exactly is happening?
If it helps to know, the protection is against many tiny DATA frames, since each one has overhead. Also, the budget is released if you consume the data.
mgr9525 commentedon Sep 28, 2026
@seanmonstar I’ve encountered a similar issue, so I reverted to 0.4.15 for now.
My use case is a reverse proxy. When both the reverse proxy and the upstream service use h2 >= 0.4.16, a large number of frontend connections are multiplexed over the same HTTP/2 connection. If the client-side network is unstable, many of the multiplexed streams may be reset, eventually causing a GOAWAY. If a large file is being downloaded on one of the streams at that time, the download is interrupted as well.
What is the recommended way to handle this kind of scenario? Is HTTP/2 unsuitable for reverse proxies, or is there a configuration or usage pattern that can avoid this behavior?