Downloaded the tar file repeatedly but each one has the same error. The unpacked tar only has the bin and lib directories.
gzip: stdin: invalid compressed data--format violated
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
The chechsums don’t match. It’s the same for the preview.
You might need to use a tool that allows you to retry a failed download such as DownThemAll. I am in Australia and have similar issues with Slicer downloads.
Thanks for the reports. I don’t recall hearing any problems about interrupted downloads. Do you connect through VPN or proxy server? How long does it take to download the installer package? If you repeat the download multiple times, are all the download attempts result in exactly the same file size?
@jcfr do you see anything in the server logs?
I think in my case it might be ISP related as my downloads from home rarely fail. The work connection is directly to our ISP without any proxy etc. and I am the network admin. All downloads are different sizes so there is no common failure point.
Here is a typical download attempt. The connection keeps failing until interrupted.
wget https://download.slicer.org/bitstream/63f5bee68939577d9867b4c7
–2023-06-01 11:09:36-- https://download.slicer.org/bitstream/63f5bee68939577d9867b4c7
Resolving download.slicer.org (download.slicer.org)… 66.162.65.219
Connecting to download.slicer.org (download.slicer.org)|66.162.65.219|:443… connected.
HTTP request sent, awaiting response… 302 FOUND
Location: https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download [following]
–2023-06-01 11:09:37-- https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Resolving slicer-packages.kitware.com (slicer-packages.kitware.com)… 216.136.40.52
Connecting to slicer-packages.kitware.com (slicer-packages.kitware.com)|216.136.40.52|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 373537536 (356M) [application/octet-stream]
Saving to: ‘63f5bee68939577d9867b4c7’63f5bee68939577d9867b4c7 9%[====> ] 35.06M 1.50MB/s in 83s
2023-06-01 11:11:02 (431 KB/s) - Connection closed at byte 36765696. Retrying.
–2023-06-01 11:11:03-- (try: 2) https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Connecting to slicer-packages.kitware.com (slicer-packages.kitware.com)|216.136.40.52|:443… connected.
HTTP request sent, awaiting response… 206 Partial Content
Retrying.–2023-06-01 11:11:05-- (try: 3) https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Connecting to slicer-packages.kitware.com (slicer-packages.kitware.com)|216.136.40.52|:443… connected.
HTTP request sent, awaiting response… 206 Partial Content
Retrying.–2023-06-01 11:11:09-- (try: 4) https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Connecting to slicer-packages.kitware.com (slicer-packages.kitware.com)|216.136.40.52|:443… connected.
HTTP request sent, awaiting response… 206 Partial Content
Retrying.
A second attempt about 10 minutes later worked.
wget https://download.slicer.org/bitstream/63f5bee68939577d9867b4c7
–2023-06-01 11:29:19-- https://download.slicer.org/bitstream/63f5bee68939577d9867b4c7
Resolving download.slicer.org (download.slicer.org)… 66.162.65.219
Connecting to download.slicer.org (download.slicer.org)|66.162.65.219|:443… connected.
HTTP request sent, awaiting response… 302 FOUND
Location: https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download [following]
–2023-06-01 11:29:20-- https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Resolving slicer-packages.kitware.com (slicer-packages.kitware.com)… 216.136.40.52
Connecting to slicer-packages.kitware.com (slicer-packages.kitware.com)|216.136.40.52|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 373537536 (356M) [application/octet-stream]
Saving to: ‘63f5bee68939577d9867b4c7.1’63f5bee68939577d9867b4c7.1 100%[=========================================================>] 356.23M 1.34MB/s in 3m 50s
2023-06-01 11:33:10 (1.55 MB/s) - ‘63f5bee68939577d9867b4c7.1’ saved [373537536/373537536]
sha512sum 63f5bee68939577d9867b4c7.1
aed98e0b800054d69ca5636e13c39e11a1c633b15e3b6faafade505c04867ed5e285446f4be210073fec6a9e501089ec76f3fe82edbb57d40d72b38c2796b67b 63f5bee68939577d9867b4c7.1
The downloads are never interrupted and all have the same size. I can’t recall the download times but they were roughly the same. I do not connect through a VPN or Proxy server.
Thanks for the additional info. Hopefully @jcfr will be able to look at the server logs and we can learn something from there.
@Tanuki please provide exact time when your download failed (including timezone) and the download URL.
The downloads are never interrupted nor do they fail. My last download was on 31-05-2023.
Time zone: Africa/Accra (GMT, +0000)
https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download
Thanks for the information. Do all your downloads have the same size? Could you upload somewhere an incomplete downloaded file?
Thanks for the help so far. All the downloads have the same file size and all completed downloading without interruption.
link to the upload
Thank you, the file that you got was interesting. The file has the correct size (373537536 bytes). The first 43883184 bytes were correctly downloaded. After that point, the file content restarts from the beginning.
This indicates that the download was interrupted (it can happen for example if the server loses its patience because your network connection is slow) and then your download client thought that it could resume the interrupted download from where it was left off, but the server did not support this and just just provided the bytes from the beginning.
With some help from bing-chat, I checked if the Slicer download server supports resume:
import requests
url = 'https://slicer-packages.kitware.com/api/v1/item/63f5bee68939577d9867b4c7/download'
headers = {'Range': 'bytes=0-4'}
res = requests.head(url, headers=headers)
if res.status_code == 206:
print('Resume download is supported')
else:
print('Resume download is not supported')
The result was: Resume download is supported
Just to confirm, I’ve printed the header:
>>> res.headers
{'Server': 'nginx',
'Date': 'Mon, 05 Jun 2023 00:48:28 GMT',
'Content-Type': 'application/octet-stream',
'Content-Length': '373537536',
'Connection': 'keep-alive',
'Allow': 'DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT',
'Girder-Request-Uid': '93225529-db4f-4337-8055-363bcc8e7bb9',
'Accept-Ranges': 'bytes',
'Content-Disposition': 'attachment; filename="Slicer-5.2.2-linux-amd64.tar.gz"',
'Content-Range': 'bytes 0-373537535/373537536',
'Strict-Transport-Security': 'max-age=63072000'}
Again, 'Accept-Ranges': 'bytes' confirmed that the server can resume a download.
After this, I’ve tested if the server can actually accepts a range, by requesting file content in the range of byte 10-20:
headers = {'Range': 'bytes=10-20'}
res = requests.get(url, headers=headers)
with open('c:/tmp/slicerpackage.bin', 'wb') as f:
f.write(res.content)
This script downloaded the entire Slicer package and wrote it to file - from byte 0!
The response header tells that the server actually did not respect the range request (see Content-range):
>>> res.headers
{'Server': 'nginx', 'Date': 'Mon, 05 Jun 2023 00:56:57 GMT', 'Content-Type': 'application/octet-stream', 'Content-Length': '373537536', 'Connection': 'keep-alive', 'Allow': 'DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT', 'Girder-Request-Uid': '9bbfbc0b-c732-4ee7-a057-975401fd5fcb', 'Accept-Ranges': 'bytes', 'Content-Disposition': 'attachment; filename="Slicer-5.2.2-linux-amd64.tar.gz"', 'Content-Range': 'bytes 0-373537535/373537536', 'Strict-Transport-Security': 'max-age=63072000'}
>>> res.status_code
206
Arguably, the download client should have known better that it did not get what it asked for and use the received bytes appropriately, but I think overall the server behavior is confusing and probably incorrect. Even more so because the server returned status code of 206 = “partial content”, which is again wrong, as it provided the full content again.
Therefore, it seems that the problem is that the Slicer download server states that it supports resume, but then it ignores the requested content range information in the header and provides the full file content.
@jcfr @Sam_Horvath Could you please configure the Slicer download server so that it either states that it does not accept range requests; or fix it so that it actually respects range requests?
This will probably solve the download issues that users occasionally reported over slow/unreliable network connections.
Thanks @lassoan for the detailed analysis 
Issue is now tracked in Download backend: Disable or add support for HTTP range requests · Issue #28 · Slicer/slicer_download · GitHub