0.0%Error while parsing headersOther error? -1

[probonopd]

Using the latest continuous build on Deepin 15.4:

me@host:~$ chmod +x Downloads/zsync2-continuous-x86_64.AppImage 
me@host:~$ Downloads/zsync2-continuous-x86_64.AppImage https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage.zsync
https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage.zsync
Usable data from seed files: 0.000000%
Renaming temp file
Fetching remaining blocks
Downloading from https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage

-------------------- 0.0%Error while parsing headersOther error? -1
-1 returned
-------------------- 0.0% 0.0 kBps aborted    

failed to retrieve from zsync2-continuous-x86_64.AppImage, status -1

[probonopd]

With CURLOPT_VERBOSE=1:

me@host:~$ CURLOPT_VERBOSE=1 Downloads/zsync2-continuous-x86_64.AppImage https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage.zsync
https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage.zsync
zsync2-continuous-x86_64.AppImage.part found, using as seed file
Reading seed file: zsync2-continuous-x86_64.AppImage.part
Usable data from seed files: 0.000000%
Renaming temp file
Fetching remaining blocks
Downloading from https://github.com/TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage

-------------------- 0.0%* Hostname was NOT found in DNS cache
*   Trying 192.30.253.112...
* Connected to github.com (192.30.253.112) port 443 (#2)
* found 173 certificates in /etc/ssl/certs/ca-certificates.crt
* 	 server certificate verification OK
* 	 common name: github.com (matched)
* 	 server certificate expiration date OK
* 	 server certificate activation date OK
* 	 certificate public key: RSA
* 	 certificate version: #3
* 	 subject: 
* 	 start date: Thu, 10 Mar 2016 00:00:00 GMT

* 	 expire date: Thu, 17 May 2018 12:00:00 GMT

* 	 issuer: C=US,O=DigiCert Inc,OU=www.digicert.com,CN=DigiCert SHA2 Extended Validation Server CA
* 	 compression: NULL
* 	 cipher: AES-128-CBC
* 	 MAC: SHA256
> GET /TheAssassin/zsync2/releases/download/continuous/zsync2-continuous-x86_64.AppImage HTTP/1.1
Range: bytes=0-3747839
Host: github.com
Accept: */*

< HTTP/1.1 302 Found
* Server GitHub.com is not blacklisted
< Server: GitHub.com
< Date: Sat, 28 Oct 2017 08:25:43 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Status: 302 Found
< Cache-Control: no-cache
< Vary: X-PJAX
< Location: https://github-production-release-asset-2e65be.s3.amazonaws.com/105511842/60253304-bba3-11e7-8569-fbfaf4330e4f?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20171028%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20171028T082543Z&X-Amz-Expires=300&X-Amz-Signature=f33ee70f2a5bafe9dc43331065b8e88f198291292007f3df88566a4edfb09f84&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Dzsync2-continuous-x86_64.AppImage&response-content-type=application%2Foctet-stream
< X-UA-Compatible: IE=Edge,chrome=1
< Set-Cookie: logged_in=no; domain=.github.com; path=/; expires=Wed, 28 Oct 2037 08:25:43 -0000; secure; HttpOnly
< Set-Cookie: _gh_sess=eyJzZXNzaW9uX2lkIjoiOWUwMGFjN2VhZjRiYWM3MjYxOTJmOTI1Mzc3MDA5ODAiLCJsYXN0X3JlYWRfZnJvbV9yZXBsaWNhcyI6MTUwOTE3OTE0Mzk0Mywic3B5X3JlcG8iOiJUaGVBc3Nhc3Npbi96c3luYzIiLCJzcHlfcmVwb19hdCI6MTUwOTE3OTE0M30%3D--240ffc78cb5564f11ca2746d741ac8db3c2e7fc3; path=/; secure; HttpOnly
< X-Request-Id: 838f578fb97fa5721c55a785e70f821c
< X-Runtime: 0.048912
< Expect-CT: max-age=2592000, report-uri="https://api.github.com/_private/browser/errors"
Error while parsing headersOther error? -1
-1 returned
-------------------- 0.0% 0.0 kBps aborted    

* Closing connection 2
failed to retrieve from zsync2-continuous-x86_64.AppImage, status -1

[TheAssassin]

This is clearly a bug. The redirection is not resolved. Looks like we need more error handling.

[TheAssassin]

Cannot reproduce any more. Probably been fixed in a previous commit. Please verify.

[probonopd]

Works for me, too. But .zs-old file is left over, #7

[overheadhunter]

Just tried to update cryptomator-1.4.1-x86_64.AppImage using the latest AppImageUpdate snapshot version and got the same error:

sebastian@linux-mint:~/Downloads$ ./AppImageUpdate-x86_64.AppImage 
AppImageUpdate version 1-alpha (commit 6f2d028), build 400 built on 2019-02-07 22:44:08 UTC
Updating from Bintray via ZSync
zsync2: Target file: /home/sebastian/Downloads/cryptomator-1.4.3-x86_64.AppImage
zsync2: Reading seed file: /home/sebastian/Downloads/cryptomator-1.4.1-x86_64.AppImage
zsync2: Usable data from seed files: 49,298165%
zsync2: Renaming temp file
zsync2: Fetching remaining blocks
zsync2: Downloading from https://dl.bintray.com/cryptomator/cryptomator/cryptomator-1.4.3-x86_64.AppImage
Error while parsing headersOther error? -1

What does this error mean? Is my zsync file malformed?

Edit: Btw before using AppImageUpdate I tried using AppImageLauncher's update mechanism, which didn't work either (probably for the same reason). It just exits without any graphical error message and leaves a .part file behind (which is just a few thousand bytes smaller than the target file).

Edit2: When I download the target version into the same directory manually and run AppImageUpdate for the old version, it recognizes the target file as a seed file from which it can re-use 100%. It then loads the remaining parts (i.e. zero), verifies the checksum and exits with status code 0.

[TheAssassin]

In your case, the .zsync file has already been downloaded, otherwise we wouldn't know how much can be used from the local data. It crashed while trying to make range requests to the AppImage. This is quite strange.

Re. AppImageLauncher, please open an issue over there, that makes managing issues much easier for us, and they can be worked on more quickly.

Can you retry with export CURLOPT_VERBOSE=1?

[TheAssassin]

@overheadhunter Bintray broke/disabled range requests, the server doesn't reply properly any more. Not our fault, neither your fault, they are to blame.

@probonopd you have some contacts there, would you like to talk to them please?

[overheadhunter]

Bintray broke/disabled range requests, the server doesn't reply properly any more.

According to RFC 7233, Section 4.4 you can not rely on the server supporting range requests:

Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response.

While this is sad and I love AppImages for being able to load just the delta, the update mechanism must be prepared to deal with "200" responses and just silently load the whole file.

Maybe log a message suggesting that the update mechanism isn't as efficient due to the server's lacking support for range requests - so the AppImage's maintainer is informed about this and may choose a better server (or contact the hoster's customer support^^).

[TheAssassin]

Well, not good style, but if the standard even thinks it's okay...

Okay, let's try to fix the problem in AppImageUpdate. I'd say it's good enough to "just download" the entire file instead of trying to be overly smart and abort after all ranges have been fetched.