Excessive progress bar printing with unknown payload size #2158

staticfloat opened this Issue Dec 6, 2017 · 2 comments


None yet
2 participants

I did this

[20:08:38]$ curl -# -o /dev/null -L 'https://github.com/torvalds/linux/archive/v4.14-rc1.tar.gz' 2>&1 | tr '\r' '\n' | wc -l

I expected the following

I expected curl to output only 10 lines a second, but instead it output almost 4K lines a second. Note that this seems to happen only when the Content-Length header is not given, (which seems to be the case if you request a tarball from GitHub that hasn't been requested in a while, I suggest asking for rc1 tarballs of the Linux kernel, they don't seem to be downloaded very often, but once you download it, the Content-Length header will be provided for a short time afterward) which also seems to explain why the progress bar is locked at 100% all the time.

curl/libcurl version

$ curl -V
curl 7.47.0 (x86_64-pc-linux-gnu) libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets

operating system

ElementaryOS Loki (based on Ubuntu 16.04)

Other thoughts

My best guess is that this is because the progress "done" callback is getting called multiple times due to the Content-Length not being known.

@bagder bagder added the cmdline tool label Dec 6, 2017

bagder added a commit that referenced this issue Dec 7, 2017

curl: limit -# progress bar properly for unknown total size
Make it use a max 10Hz update frequency for this case as well. Return early if
the "point" hasn't moved since last invoke.

Fixes #2158

bagder commented Dec 7, 2017

Ack. Pending fix now in #2163...


bagder commented Dec 7, 2017


@bagder bagder closed this in b5881d1 Dec 7, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment