Implement -u

[probonopd]

As zsync2 is meant to be a drop-in replacement for zsync, it should support -u:

Use case (from AppImage/AppImageKit#519 (comment)):

if I'm on continuous and want to test the "dontDisconnectFacebook" channel, I could switch to that without having to download 80MB... I like that last example a lot because that's a very very frequent use case for our testers.

Test case:

# Get an AppImage
wget https://github.com/Subsurface-divelog/subsurface/releases/download/continuous/Subsurface-35c501677-x86_64.AppImage

# Say, you want to go to another (random) channel, like "travisTest2"
wget https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/Subsurface-db64ec0af-x86_64.AppImage.zsync

# Let's see how well the original zsync fares
sudo apt -y install zsync
zsync -i Subsurface-35c501677-x86_64.AppImage Subsurface-db64ec0af-x86_64.AppImage.zsync 
URL 'Subsurface-db64ec0af-x86_64.AppImage' from the .zsync file is relative,
but I don't know the referer URL (you probably downloaded the .zsync separately
and gave it to me as a file). I need to know the referring URL (the URL of the .zsync)
in order to locate the download. You can specify this with -u
(or edit the URL line(s) in the .zsync file you have).

# But that also breaks; most likely due to zsnyc not handling GitHub's redirects properly
zsync -i Subsurface-35c501677-x86_64.AppImage Subsurface-db64ec0af-x86_64.AppImage.zsync -u https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/
Read Subsurface-db64ec0af-x86_64.AppImage.part. Target 99.3% complete.      
failed to retrieve from Subsurface-db64ec0af-x86_64.AppImage
Aborting, download available in Subsurface-db64ec0af-x86_64.AppImage.part

# Now, let's try with zsnyc2
./zsync2-continuous-x86_64.AppImage -i Subsurface-35c501677-x86_64.AppImage Subsurface-db64ec0af-x86_64.AppImage.zsync -u https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/
Flag could not be matched: 'u'

# Now, let's try with zsnyc2 without -u
./zsync2-continuous-x86_64.AppImage -i Subsurface-35c501677-x86_64.AppImage Subsurface-db64ec0af-x86_64.AppImage.zsync
Reading seed file: Subsurface-35c501677-x86_64.AppImage
Usable data from seed files: 99.301443%
Renaming temp file
Fetching remaining blocks
URL 'Subsurface-db64ec0af-x86_64.AppImage' from the .zsync file is relative,
but I don't know the referer URL (you probably downloaded the .zsync separately
and gave it to me as a file). I need to know the referring URL (the URL of the .zsync)
in order to locate the download. You can specify this with -u
(or edit the URL line(s) in the .zsync file you have).

[probonopd]

Passing in the URL to the zsync file directly works though (and is even more elegant):

./zsync2-continuous-x86_64.AppImage -i Subsurface-35c501677-x86_64.AppImage https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/Subsurface-db64ec0af-x86_64.AppImage.zsync

The original zsync cannot do it:

 zsync -i Subsurface-35c501677-x86_64.AppImage https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/Subsurface-db64ec0af-x86_64.AppImage.zsync
failed on url https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/Subsurface-db64ec0af-x86_64.AppImage.zsync
could not read control file from URL https://github.com/Subsurface-divelog/subsurface/releases/download/continuous-travisTest2/Subsurface-db64ec0af-x86_64.AppImage.zsync

[TheAssassin]

You're right though, -u is missing. The way you use it works as well, but -u is part of the legacy interface, which we aim to support in total. I'll add this flag as a dummy as soon as possible, and will try to implement it as soon as I find an elegant way to do it with the existing program flow.

[probonopd]

As a workaround, it may be sufficient to give an error message when the user tries to use -u, telling him to provide the URL to the zsync file to -i instead. May be sufficient, and whoever is not happy with it is welcome to send a PR :-)

[TheAssassin]

May be sufficient, but there's cases in which the .zsync file is not available on the server, but the file itself is, although the path to this file is relative in the .zsync file.

[probonopd]

I mean, having a local .zsync file but not on the server is probably not a relevant use case.

[TheAssassin]

Not relevant, yes, but possible, and supported by zsync-curl. Definitely not a priority.

[ferion11]

Not relevant, yes, but possible, and supported by zsync-curl. Definitely not a priority.

I think you are underestimating this feature. This feature can make zsync2 widely used. This allows zsync file repositories to be separated from the original links. And zsync file repositories are small and easy to store, and easy to be integrated with package managers from linux distributions. And the only feature that zsync2 lacks for that, is the possibility to easily change the url (mirror) that will be used together with the zsync file.
I even thought of making one zsync file repository for all GentooLinux packages (using github plus travis-ci).

[probonopd]

@ferion11 could you make a pull request?

[ferion11]

@ferion11 could you make a pull request?

I will take a look at the code. But I have to make GentooLinux ebuilds for "zsync2", "lib/cpr" and "lib/args" first.

[ferion11]

Gentoo ebuild (online on danrepo) and the implementation of "-u" done.

I tested it with github links and work well. But I found one bug using the kernel.org links:
"zsync_legacy: got non-HTTP response 'HTTP/2 206"

[probonopd]

Thanks for sending the PR @ferion11, I've commented there.

[ferion11]

@probonopd , It looks like the @TheAssassin hasn't been active on github for some time.
The bug "zsync_legacy: got non-HTTP response 'HTTP/2 206" has nothing to do with this pull request. It was already there before the PR.
And the HTTP/2 is fully backwards-compatible with HTTP/1.1. Perhaps, removing the check with the HTTP version, everything will work normally, for both versions. But this is another problem for another pull request, which may not even be necessary if #30 is implemented. And #30 is much more urgent, as the current code doesn't work normally with some downloads as reported in #31 and #43 (seems to be the same bug).
Can you contact the @TheAssassin (using other way) for this?

[TheAssassin]

@ferion11 thanks for your PR. Going to review now. The best way to get in touch is usually via IRC in #appimage on Freenode by the way. Or just write me a mail next time.

[ferion11]

@TheAssassin Glad to see you back. Thanks for the extra contact way too :)