flatpak-builder icon indicating copy to clipboard operation
flatpak-builder copied to clipboard

Revert compressed downloads

Open bbhtt opened this issue 2 months ago • 1 comments

In 1.3.5 flatpak-builder switched to defaulting to compressed downloads using curl which sends an empty string as the accept encoding header.

https://github.com/flatpak/flatpak-builder/pull/556

Now, some websites/servers are broken and don't understand the empty value of accept encoding. They fail with:

Downloading sources
Downloading https://www.quut.com/gsm/gsm-1.0.23.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0 66158    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
Failed to download sources: module gsm: Unrecognized content encoding type. libcurl understands deflate, gzip, br content encodings.

There's also another issue where some archives were decompressed, see https://github.com/flatpak/flatpak-builder/pull/580

To combat these, disable-http-decompression was introduced shortly after https://github.com/flatpak/flatpak-builder/pull/581 to opt out on a per-source basis.

I'm considering that we should revert https://github.com/flatpak/flatpak-builder/pull/556 and/or optionally add an enable-http-compression option (and drop disable-http-decompression).

It may be true that servers / websites are broken but sending an empty accept encoding is not the default behaviour of curl, wget cmdlines or any browsers. It is quite confusing to see flatpak-builder failing to download a file which other common software can easily download.

Alternatively, we can detect this case (I don't know if it is possible) and print a more helpful message or document this somehow, so people can find it easily.

bbhtt avatar Oct 18 '25 02:10 bbhtt