Firefox Download Failed at 99%? How to Resume It Instead of Starting Over

Your 20 GB model file reaches 99%, the Wi-Fi hiccups, and Firefox shows "Failed". You click Retry and it starts again from 0 bytes. Sometimes that's Firefox's fault. Often it isn't, and no setting will save that download.

Here's how to tell which case you're in, the one about:config change and the .part trick that sometimes rescue a Firefox download, and the curl and aria2c commands I use now for anything over a few gigabytes.

Why Firefox can't resume some failed downloads

Resuming a download depends on one HTTP feature: range requests. The client says "send me bytes 19,800,000,000 onward" and the server answers 206 Partial Content. MDN's range requests guide spells out the rule: if range requests aren't supported, "an 200 OK status is sent back and the entire response body is transmitted." Every client starts from zero in that case, whether it's Firefox, curl or anything else.

You can check before you start a big download:

curl -sIL "https://example.com/big.iso" | grep -i -E 'accept-ranges|content-length|location'

If you see accept-ranges: bytes, the server can resume. If the header is missing, MDN says that "indicates the server doesn't support partial requests."

The second reason is newer and catches people downloading models: signed URLs that expire. The link you clicked isn't the one serving the bytes. It redirects to a CDN URL with a signature and an expiry time. You can see it on Hugging Face:

curl -sI "https://huggingface.co/openai-community/gpt2/resolve/main/model.safetensors" | grep -i '^location'

When I ran that, the 302 pointed at us.aws.cdn.hf.co with an Expires= timestamp exactly 3600 seconds in the future. That's a one-hour signature. If the connection drops after that hour, the browser tries to resume against a dead URL and gets a 403. In the Hacker News thread on this topic, one commenter describes servers handing out single-use links: the first request gets the file, and once that connection drops, every later request to the same URL gets 410 Gone, so there's nothing to resume against.

The third reason is cookies and auth. A download from behind a login only works with your session attached. Retrying without the session can get you a login page saved as big.iso.

The Firefox setting: network.http.response.timeout

The TIL post that kicked off the HN discussion points at one pref:

1. Open about:config.
2. Search for network.http.response.timeout.
3. Change it from 300 to 0 (no timeout) or a very large number.

The 300-second default goes back to Firefox 29. In bug 1005808, Mozilla's networking team defended it: they "consider 5 mins to be a significant time to wait without even a partial response from the server", and the timeout lets Firefox recover from connections that NATs and firewalls drop silently. The bug was closed WONTFIX.

The TIL author says that setting it to 0 makes big downloads "both resumable and at least a little more stable", and adds "I don't understand why this works, but experimental testing supports it."

I'd treat that as a cheap thing to try. On HN, sunaookami called the theory "placebo and untrue", pointing out that the response timeout isn't used when TCP keepalive is on, which it is by default. userbinator said they had resumed a download without trouble less than a month earlier, with the pref left at 300. My view is that the pref may help when a connection stalls rather than resets, but it does nothing about missing Range support or an expired URL. Flip it if you want, just don't count on it.

The .part trick for a download Firefox gave up on

While a download is running, Firefox writes to filename.part. When the download fails and Retry restarts from zero, this manual swap (described on HN and linked from the TIL post) can save the bytes you already have:

1. Move or copy big.iso.part somewhere else before you touch the download.
2. In the Downloads panel, retry (or restart) the download.
3. Pause it straight away.
4. Replace the new tiny big.iso.part with your old, large one, keeping the same name.
5. Hit Resume. Firefox asks the server for bytes from the end of the file on disk.

This only works if the server supports ranges and the new URL serves the same file. Another HN commenter, cnrcode, pointed out the catch: "Resume requests only check the range." If the file changed on the server between attempts, Firefox can join the old start onto the new end and you get a corrupted ISO that looks fine. Check the hash after any resumed download:

sha256sum big.iso
# compare against the SHA256SUMS file the project publishes

Resume big downloads with curl, wget or aria2c instead

For anything over about 5 GB, I don't start the download in Firefox at all. The browser download manager has been unreliable here for a long time (the TIL post links a forum thread about it from 2005), and command-line tools let you control retries.

curl -C - with retries

-C - tells curl to "automatically find out where/how to resume the transfer" (curl man page). Add retries so a short network drop doesn't end the transfer:

curl -L -C - -O \
  --retry 20 --retry-delay 5 --retry-all-errors \
  "https://releases.example.org/distro-24.04-desktop-amd64.iso"

--retry-all-errors was added in curl 7.71.0. Without it, curl only retries errors it considers transient. If curl stops anyway, run the same command again and it continues from the existing file. I tested this against a local server with half the file already on disk, and the result matched the original byte for byte. Against a server without range support, curl refuses with curl: (33) HTTP server does not seem to support byte ranges. Cannot resume. and leaves your partial file alone. I'll take that over Firefox silently starting from zero.

If the download needs your login, use Firefox's Network tab: right-click the request, choose Copy Value → Copy as cURL, then add -C - -O to the end. The cookies come along. One HN commenter does this and runs the curl command on a VPS, then copies the finished file home.

wget -c -O "$filename" "$url" does the same job. The TIL author uses it and calls it fairly stable.

aria2c for flaky networks and huge files

aria2 splits a file across several connections and keeps a .aria2 control file next to the download that records which chunks are done:

aria2c -c -x 8 -s 8 --max-tries=0 --retry-wait=5 \
  "https://releases.example.org/distro-24.04-desktop-amd64.iso"

Notes from the manual:

• -c resumes, and it works on a download "started by a web browser or another program", so you can point it at Firefox's partial file after renaming it.
• -s defaults to 5 connections and -x (connections per server) defaults to 1. You need both for the split to happen.
• --max-tries=0 means unlimited. The default is 5.
• Don't delete the .aria2 file. The manual is clear: "Normally if you lose a control file, you cannot resume download."
• --load-cookies reads Firefox's cookies.sqlite directly for logged-in downloads, if aria2 was built with libsqlite3.

One HN commenter found aria2 still gives up on really bad connections and wrapped it in a bash script that reruns it until the download succeeds. Something like this does it:

until aria2c -c -x 8 -s 8 "$URL"; do sleep 10; done

Hugging Face model files: use hf download

For Hugging Face, neither curl nor aria2 can fix an expired signature halfway through, because the signed URL they hold just stops working. Use hf download from huggingface_hub, which can request fresh signed URLs when the old ones die. It has its own problems, though. A transformers issue shows a download that hit repeated 403s on signed URLs, refreshed them, and then hung without an error. Setting HF_HUB_DISABLE_XET=1 avoided it. That particular bug was on HF's side and was fixed before the issue was closed, but the Neutree FAQ recommends the same thing for unstable networks, noting the HTTP path is slower but more reliable.

Which tool when

Browsers are fine for PDFs and installers. For a 20 GB file they're the wrong tool. People are still arguing about one 300-second pref 12 years after Firefox 29, and that tells you how much attention the download manager gets.

What's the biggest download you've ever lost at 99%? And do you still trust your browser with big files, or did you move to curl/aria2 long ago? If you think the timeout pref really works, tell me why in the comments.

Sources

• Making big downloads resumable in Firefox (TIL)
• Hacker News discussion
• Mozilla bug 1005808: 300 s response timeout
• MDN: HTTP range requests
• curl man page
• aria2c manual
• transformers issue 45797
• Neutree FAQ: Hugging Face download hangs