This tools is quite friendly when synchronizing mirrors, I've hit my head for a few days in regards to synchronizing mirrors, Icinga being amongst them.
From the debugging I've done, the common denominator is how aptly does not provide an uncompressed Contents- file, such as Contents-amd64. You can download the file without the file extension as the Release says is available, the Header "Content-Location" is returned with the filename you are really getting (filename.gz), which the net/http library might not handle that well.
This tools is quite friendly when synchronizing mirrors, I've hit my head for a few days in regards to synchronizing mirrors, Icinga being amongst them. From the debugging I've done, the common denominator is how aptly does not provide an uncompressed Contents- file, such as Contents-amd64. You can download the file without the file extension as the Release says is available, the Header "Content-Location" is returned with the filename you are really getting (filename.gz), which the net/http library might not handle that well.
Example: As a consequence when trying to get https://packages.icinga.com/debian/dists/icinga-buster/main/Contents-amd64, you get served https://packages.icinga.com/debian/dists/icinga-buster/main/Contents-amd64.gz while the function checks against the file without compression. If the function checks in case it fails against a .gz entry for the same filename, it would work.
Toml to replicate the error: