indeterminate progress

[jeromectm]

Since version 1.19, the download progress is indeterminate (and the progress strings shows something like "[current] MB of [current] MB", instead of "[current] MB of [total] MB". The HTTP server from which I download probably does not return the size, but the appcast does, and it was working before version 1.19.
Here is my appcast:
https://services.ctmdev.com/cgi-bin/sparkle?appcast=FTProfessional_appcast

<?xml version="1.0" encoding="utf-8"?> <rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle" xmlns:dc="http://purl.org/dc/elements/1.1/"> <channel> <title>FoxTrot Release Notes</title> <description>Most recent changes with links to updates.</description> <language>en</language> <item> <title>Version 6.5.2</title> <sparkle:releaseNotesLink>https://services.ctmdev.com/VersionChecking/FoxTrot/FTProfessionalReleaseNotes.html</sparkle:releaseNotesLink> <enclosure sparkle:version="6.5.2" sparkle:minimumSystemVersion="10.9" url="http://powermail.simplenet.com/FTProfessional6.5.2.tbz" length="7563321" type="application/octet-stream" sparkle:dsaSignature="MCwCFEuO5jPsxjTKoDJMeOXIA7DoWdCDAhRDO+tReuSk0q2f4yO+gt5WRvQz7A==" /> </item> </channel> </rss>

[kornelski]

Yeah, we've rewritten the download code recently (to remove deprecated APIs). It's likely that we're depending on HTTP now rather than appcast info.

It'd be ideal if you emitted Content-Type header from your cgi-bin.

[nightbirdsevolve]

@kornelski Same issue here, progress is indeterminate even tho server sends a Content-Length header… what can we do to make it work?

[kornelski]

Investigate the downloader code — maybe it's not reading the header from the response.

[nightbirdsevolve]

For what it's worth: disabling apache gzip solved my indeterminate progress issue. But still could be nice of Sparkle to fallback to the length attribute. I'll investigate later :)

[moubry]

For anyone stumbling across this in the future, I was having the issue of an indeterminate progress indicator appearing. Simply adding the Content-Length HTTP header to the app ZIP file’s download/response fixed the issue. So Sparkle definitely uses the Content-Length HTTP header to know how big the download is going to be.

Here's a relevant subset of the HTTP response headers I'm sending:

...
Content-Type: application/zip
Content-Length: 49884791
Content-Disposition: attachment; filename="MyApp_0.2.1.zip"
Content-Transfer-Encoding: binary
...

^ Simply adding Content-Length to these other headers is what fixed it. I have other headers besides this, but these are the ones that seemed most relevant to this issue.

Re: what @nightbirdsevolve mentioned, my web server is not gzipping the response either.

[zorgiepoo]

I think we're supposed to fall back to length in appcast item if reported http header length is 0. But if the reported length from http server is wrong, we don't try to fix it (though we emit a console warning). Might be worth re-investigating what the logic actually is.