Downloads may fail with an unreliable connection

[hn3000]

Description of the problem

Auto updates in iTerm2 (not my own app) fail because downloads are very slow via my internet connection.

(The connection speed is a completely separate rabbit hole that seems to be a game of chicken between Deutsche Telekom and Cloudflare, while workarounds exist, auto updates failing because I don't have my VPN connected seems not ideal.)

Looking at the current code of the DownloadDriver

Sparkle/Sparkle/SPUDownloadDriver.m

Line 115 in 2c95fa4

NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:requestURL cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:30.0];

, I only see a hard-coded timeout and the default timeout appears to be "30s without activity". It would be useful if that timeout could be increased.

When I try to download the update using curl, the download takes about 5 minutes. (With a VPN connection it takes less than a second, but like I said -- I'd prefer for the auto update to not fail regardless of that issue.)

Do you use Sandboxing in your app?

Not sure, and I don't know if that's relevant here.

Version of Sparkle.framework in the latest version of your app

not sure

Version of Sparkle.framework in the old version of app that your users have (or N/A)

not sure

Sparkle's output from Console.app

didn't find anything

Steps to reproduce the behavior

"Check for Updates ..." -> an update is available,
"Download now" ... progress starts, stops without detailed reason after one or two minutes

Additional context

https://groups.google.com/g/iterm2-discuss/c/uB3odleHKLs/m/HXzOv9MWAAAJ

[zorgiepoo]

What timeout do you want? I believe iTerm uses 60 seconds which is the default (for NSURLRequest/NSURLSession) and it's not good enough for you (60 seconds without activity seems decently long...). We can make it longer, and in any case I think all the 30 second timeouts in the top of Sparkle's repo uses should be changed at 60 seconds minimum which matches the Foundation default..

It doesn't matter much to me* if an app can customize the timeout, because a decision will have to be made on what a good default timeout is either way is and it isn't specific to just one app using the framework.

(*the update download request is customizable but the feed and release notes requests aren't, but this is distracting to the issue needing to be solved)

--

For clarity this sounds more like an "unreliable connection" issue than a "slow connection" issue. 60 seconds without receiving any data is a long time. You can have a slow and stable connection and not have this problem.

curl may also not download files the same way as NSURLSession does. I'm not sure the timeout is the culprit.

[zorgiepoo]

I kicked off a custom build here so you can test changing the timeout: #2672

Grab the Sparkle distribution build from that PR CI created here: https://github.com/sparkle-project/Sparkle/actions/runs/12210812033 (scroll down and download the Sparkle-distribution-xcode16.1.tar.xz artifact -- you may need to resize the page in Safari)

Run sparkle-cli from the distribution and point it to an old version of iTerm.app (e.g. version 3.5.9)

> env SPARKLE_TIMEOUT=60.0 ./sparkle.app/Contents/MacOS/sparkle --check-immediately --verbose /Applications/iTerm.app/
Checking for Updates...
2024-12-06 22:52:28.758 sparkle[57518:13895129] SPARKLE_TIMEOUT: 60.000000

Alter the SPARKLE_TIMEOUT env variable passed to sparkle-cli to test how downloading works with specifying different timeouts. (Note the timeout that is used is logged so you can verify the custom timeout you set).

If GateKeeper complains about running sparkle-cli first run this to remove that check (the binary is adhoc signed).

xattr -r -d com.apple.quarantine ./sparkle.app

I would try timeouts like 30, 60, 120, and 240. If the timeout interval is really the issue in your case, then you should be able to reproduce a failure with intervals 30 and 60, and less likely to reproduce a failure with higher intervals. If you can reproduce a failure with all timeout intervals, then the issue is not likely tied to the timeout interval.

[hn3000]

I don't know what to do -- the problem with my internet connection has gone away, where up til yesterday it would always take around 5 minutes to download an iterm2 update, even after I reconnected my internet connection, it's now always quick and takes less than 2 seconds.

All the other slow sites are now quick as well.

I did tweet at Cloudflare and Telekom_hilft the day before it stopped being an issue, but I don't believe it's realistic to think that was the reason it got fixed. The community support site of Deutsche Telekom has multiple threads mentioning the problem, so maybe it finally got addressed.

Thanks for the custom build, I'll keep checking download speeds and will use the command you mentioned above if the speeds drop back to the super throttled state, but currently the downloads always succeed, no matter the timeout I set.

So, like I said -- nothing I can do at the moment, but wait. This hasn't happened before in the last few months.

[zorgiepoo]

As far as the timeoutInterval goes, it isn't related to the download speed as long as you receive any data within the timeout interval, which iTerm is using a version of Sparkle that is set to 60 seconds (for the update download, but the feed/release notes are 30 seconds). If you are not receiving any data in 60 seconds, then it "looks" like the connection dropped. If you are actually hitting an issue that is unrelated, then adjusting the timeout interval won't matter.

Going to convert this into a discussion for now. Let us know if you are able to pinpoint on anything if you hit your issue again. In #2673 I will change the code to use the default 60 second timeout interval again.