Firefox has shipped every version since v28 (circa 2014) with a network timeout that quietly sabotages large downloads. The setting, network.http.response.timeout, defaults to 300 seconds — five minutes — after which Firefox appears to treat the connection as dead. For small files, you never notice. For anything big enough to matter, this default makes resuming a failed download unreliable or impossible, even when the server explicitly supports HTTP range requests. The fix is absurdly simple: open about:config, set network.http.response.timeout to 0, and resumable downloads start behaving like you'd expect. The author reports that this also improves general stability of large downloads, though the mechanism isn't fully understood. The suspicion is that Firefox's internal retry logic — the hidden attempts it makes before declaring a download failed — gets cut short by the timeout, preventing the browser from reconnecting to the server and picking up where it left off. What makes this genuinely interesting is the .part file behavior. Firefox creates .part files during downloads — partial files that should, in theory, serve as the checkpoint for resumption. But experimentally, Firefox will ignore an existing .part file without the timeout fix in place. This suggests that Firefox's resume mechanism depends more on the live connection state than on the artifact sitting on disk, which is architecturally backwards from how tools like wget handle the same problem. The author notes this has been a known issue in some form since 2005 — two decades of intermittent bug reports and workarounds. There's even a documented manual .part shuffle that forces Firefox to resume, which involves renaming files by hand. The fact that this workaround exists and is documented tells you everything about how long users have been routing around this behavior. For anyone who's given up on Firefox for large downloads, the non-Firefox escape hatch is wget -c -O "$filename" "$url", which handles resumption reliably because wget treats the partial file on disk as the source of truth, not the connection state. This is the correct architecture for download resumption, and it's been correct since the 1990s. The author is honest about the limits of this investigation: no source code was consulted, no definitive root cause identified. This is empirical troubleshooting — careful experimentation that produces a working fix without a complete explanation. That's useful and worth sharing, but it also underscores how opaque Firefox's download internals remain, even to technically capable users. The broader takeaway is architectural: a browser that millions of people rely on for downloading files has a default configuration that actively breaks file downloads, and the fix has been hiding in about:config for over a decade. This isn't a feature request. It's a default that should have been changed years ago.
