Avoid 416 error: Handlet presence of a (previously) completed archive download

[SystemKeeper]

Noticed while testing some changes to the updater:

2025-10-03T16:17:44+0000 BzQpH9dVFp [info] previous download found; resuming from 291.18MiB
2025-10-03T16:17:44+0000 BzQpH9dVFp [warn] fail to download archive from https://github.com/nextcloud-releases/server/releases/download/v32.0.0/nextcloud-32.0.0.zip. Error: 416

It's a bit weird, as 291.18MiB is the full size of the download. In the end we should handle the error 416 and do a full download.

FYI @joshtrichards since you implemented the resume logic.

[joshtrichards]

Currently it does not have a dedicated check to detect if a file is already fully downloaded. The logic assumes that the archive is incomplete if it exists at all, because the extraction step is supposed to remove it. However, the deletion might fail for some reason.

This can lead to an issue where an open-ended Range request - specifically Range: $size- where $size is the total file size - is sent. Instead of being a harmless no-op (which feels more natural to me), this is an unsatisfiable request that will cause the server to return a 416 Range Not Satisfiable error.

To correctly handle this scenario, I believe we should perform a HEAD request on the archive URL. This will allow us to get the Content-Length header for a size comparison and avoid an unnecessary Range request if the file is already complete then avoid this error entirely. EDIT: There's also a chance we already have the size from earlier we can use; don't recall offhand.

[joshtrichards]

In the end we should handle the error 416 and do a full download.

Is there a reason you suggested a full download rather than just skip the download? I was thinking the other way around, but might be overlooking something.

[SystemKeeper]

Is there a reason you suggested a full download rather than just skip the download?

It was more the idea of „what happens if the server does not support the range header“ and then we can’t recover from that. But most likely there would be no 416 in this case, but still we might need to handle some cases?