Skip to content
HN On Hacker News ↗

Making big downloads resumable in firefox

▲ 287 points • 136 comments • by speckx • 3w ago • HN discussion ↗

Pangram verdict · v3.3

We believe that this entire text is human-written.

0 %

AI likelihood · overall

Human
100% human-written 0% AI-generated
SEGMENTS · HUMAN 1 of 1
SEGMENTS · AI 0 of 1
WORD COUNT 288
PEAK AI % 0% · §1
Analyzed
Oct 13
backend: pangram/v3.3
Segments scanned
1 windows
avg 288 words each
Distribution
100 / 0%
human / AI fraction
Verdict
Human
Pangram v3.3

Article text · 288 words · 1 segments analyzed

Human AI-generated
§1 Human · 0%

firefox For whatever reason, Firefox 28 and newer (i.e. every modern version after like 2014) ships with network.http.response.timeout set to 300 seconds. This seems to interfere with resuming big downloads, as well as the general stability of big downloads.Setting network.http.response.timeout to 0 (or something very big) in about:config seems to make big downloads both resumable and at least a little more stable. I don't understand why this works, but experimental testing supports it.Note that this assumes the server supports resumable downloads; if it doesn't, no settings in firefox or any other browser are going to help. However, the problem this fixes is firefox being unable to resume a resumable download on error. I don't entirely know if this is the case, but it experimentally looks like resumable downloads in firefox rely on connection timeouts rather than the .part files they download. Firefox will happily ignore an existing .part without this option, and I do not understand why.Resumable downloads in firefox generally appear to be fairly unstable though. This has been a known problem in some form since as far back as 2005. I also found that there's a manual .part shuffle to make firefox actually resume downloads, but I'm not doing that shit. As a non-firefox workaround, using wget -c -O "$filename" "$url" also works, and wget overall appears to be fairly stable.I do also suspect firefox does some hidden retries if it can before it considers the download to have failed - from some experimental testing, it does appear that this is at least partly related to network.http.response.timeout, and that exceeding the timeout interferes with this process.I have not attempted to confirm any of this with FF's source code, because I have no clue where to look.