On 13.09.2022 13:42, Per Jessen wrote:
Andreas Schwab wrote:
On Sep 13 2022, Per Jessen wrote:
From http://download.opensuse.org, I am however given a 302 redirect, to the versioned file, but not for the checksum file.
With
$ rsync rsync.opensuse.org::opensuse-full/opensuse/distribution/leap/15.4/iso/
you can see that all the unversioned *.iso files are symlinks, but none of the *.sha256 files.
Exactly. If the sha256 files were also symlinks, maybe pontifex would treat them the same way and send redirects? I'll have to check the apache config, but it seems to me we are doing this on purpose.
The problem is that end result depends on client software (and client options) and there is no configuration that would work with any combination of links and clients. wget ... follows redirects but stores files under original name, so openSUSE-Leap-15.4-NET-x86_64-Media.iso is stored as openSUSE-Leap-15.4-NET-x86_64-Media.iso and linking openSUSE-Leap-15.4-NET-x86_64-Media.iso.sha256 to a file that contains openSUSE-Leap-15.4-NET-x86_64-Build243.2-Media.iso name will fail checksum. wget --trust-server-names ... will store file under redirected name, so linking checksum will work. Of course it fails now. curl -LO ... follows redirect but stores file under original name. See above for wget. curl does not have the equivalent of wget --trust-server-names. Both firefox and chromium store file under redirected name when downloading from download.o.o; of course when downloading from something like https://rsync.opensuse.org/ there is no redirect and so filename in .sha256 would not match. Using links simplifies download frontend (get.o.o) which may have static configuration pointing at ...-Media.iso which is magically resolved to the latest image. But it is never ending source of confusion as far as I remember.