Repository navigation
[Feature request]: Retry and resume on "Stream error in the HTTP/2 framing layer" #6824
Description
Checklist
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Suggestion
Sometimes flathub has issues like the recent flathub/flathub#10099 and flatpak/flatpak#1120 from 2017 where the download fails because of a server issue that causes a "Stream error in the HTTP/2 framing layer".
flathub/flathub#10099 has been fixed, but before it was fixed I found in flatpak/flatpak#605, which is about a different error, that apparently flatpak does retry downloads, so I used curl with retry and resume
❯ curl -O -C - --retry 7 https://dl.flathub.org/repo/objects/94/6c2b5c57340e5c6b6a8e13f881976167d28161e42c45d5d6876cbeba64fb66.filez
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
37 2.51M 37 959.9k 0 0 722.6k 0 00:03 00:01 00:02 960.8k
curl: (92) HTTP/2 stream 1 reset by server (error 0x1 PROTOCOL_ERROR)
And again with --retry-all-errors and it finally worked
❯ curl -O -C - --retry-all-errors --retry 7 https://dl.flathub.org/repo/objects/94/6c2b5c57340e5c6b6a8e13f881976167d28161e42c45d5d6876cbeba64fb66.filez
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
77 2.51M 77 1.95M 0 0 602.1k 0 00:04 00:03 00:01 658.1k
curl: (92) HTTP/2 stream 1 reset by server (error 0x1 PROTOCOL_ERROR)
Warning: Problem (retrying all errors). Retrying in 1 second. 7 retries left.
100 513.7k 100 513.7k 0 0 579.2k 0 0
This can't be reproduced anymore because flathub fixed it, but it will likely happen again.
Since flatpak uses libcurl, it just needs to be configured to retry on all errors, so we don't need to wait for flathub to fix their server whenever this happens again.
Activity
[-][Feature request]: Retry and resume on "Stream error in the HTTP/2 framing"[/-][+][Feature request]: Retry and resume on "Stream error in the HTTP/2 framing layer"[/+]Deep-Axe commentedon Sep 14, 2026
The
.filezdownloads shown here go throughostree_repo_pull_with_options(), so their retry behavior belongs tolibostree,Flatpak’s separate HTTP helper (
flatpak-utils-http.chandles extra-data, OCI and metadata/conf downloads).curl --retry-all-errorsis curl CLI policy, not a libcurl option Flatpak can enable. Plain--retryalso does not cover exit 92 as retryable.Libostree has already enabled this equivalent by default since v2023.7 (ostreedev/ostree#2843, closing ostreedev/ostree#2570):
retry-all-network-errorsdefaults to true, with five retries per download (n-network-retries). Its curl backend maps non-file libcurl failures such asCURLE_HTTP2(92) to a retryableG_IO_ERROR_TIMED_OUT. Those retries are logged at debug level only, so seeing the final[92]message does not mean no retries occurred.Partial-object resume is not present in the libostree curl fetcher ( each retry restart the object from offset 0). The existing request is ostreedev/ostree#639.
flathub/flathub#10099 was caused by a server cache-key collision serving inconsistent compressed representations of the same object. Range responses disagreed on size and ETag, so neither retrying nor resuming could reliably repair it. Retrying might occasionally hide that failure by hitting a consistent cache node.
The issues is already implemented for retries. The remaining resumable-download work belongs to libostree and overlaps ostreedev/ostree#639.