Slicer uses girder as storage backend for application packages. Unfortunately, girder has a bug: HTTP range requests are implemented incorrectly It would be OK if the server did not support it, but instead the server claims it can do it, but actually ignores the requested range parameters. The issue is described in detail here:
I’ve been downloading Slicer on various computers over various internet connections and usually the speed is between 3 MB/sec and 100 MB/sec. The entire package is downloaded within one minute, there are no interruptions, no need for resumes, so the HTTP range request bug has no impact. If the download speed for some reason is unusually slow (e.g., 0.3MB/sec), then the connection may be interrupted and your download client may then try to use “resume” feature (HTTP range request), which will result in an invalid downloaded file or other failure.
The problem will get higher priority if we get more complaints or we can get significant funding for improving the hosting infrastructure. But for now the approach will remain “watch and wait”.