ftp.funet.fi seems to be badly misconfigured as it unconditionally serves .gz files as
Content-Type: application/xml
Content-Encoding: x-gzip
even if accept-encoding headers is not passed. This leads to client failures as in this case HTTP library transparently decompressed the content, while client code still expecting compressed content.
% curl -I https://ftp.funet.fi/pub/mirrors/ftp.opensuse.com/pub/opensuse/update/leap/15.6/oss/repodata/2cd535dd8479340ddfb645a33e939dc7431947006524bd6f79fcacc04dbe5b1f-primary.xml.gz
HTTP/1.1 200 OK
Date: Wed, 20 May 2026 14:51:23 GMT
Server: Apache/2.4.67 (Unix) OpenSSL/3.5.5
Last-Modified: Mon, 18 May 2026 10:34:18 GMT
ETag: "b0054-652151ad5dcbb"
Accept-Ranges: bytes
Content-Length: 720980
Content-Type: application/xml
Content-Encoding: x-gzip
Here are responses from correctly behaving mirrors:
% curl -I https://opensuse.koyanet.lv/update/leap/15.6/oss/repodata/2cd535dd8479340ddfb645a33e939dc7431947006524bd6f79fcacc04dbe5b1f-primary.xml.gz
HTTP/2 200
server: nginx
date: Wed, 20 May 2026 14:52:46 GMT
content-type: application/gzip
content-length: 720980
last-modified: Mon, 18 May 2026 10:34:18 GMT
etag: "6a0aeb2a-b0054"
strict-transport-security: max-age=31536000; includeSubDomains
x-frame-options: DENY
x-content-type-options: nosniff
content-security-policy: frame-ancestors 'none'; upgrade-insecure-requests; base-uri 'none'; form-action 'none'; default-src 'none';
referrer-policy: no-referrer, strict-origin-when-cross-origin
accept-ranges: bytes
% curl -I https://mirror.aardsoft.fi/opensuse/update/leap/15.6/oss/repodata/2cd535dd8479340ddfb645a33e939dc7431947006524bd6f79fcacc04dbe5b1f-primary.xml.gz
HTTP/2 200
server: nginx/1.21.5
date: Wed, 20 May 2026 14:44:00 GMT
content-type: application/octet-stream
content-length: 720980
last-modified: Mon, 18 May 2026 10:34:18 GMT
etag: "6a0aeb2a-b0054"
accept-ranges: bytes
ftp.funet.fi seems to be badly misconfigured as it unconditionally serves .gz files as
even if accept-encoding headers is not passed. This leads to client failures as in this case HTTP library transparently decompressed the content, while client code still expecting compressed content.
Here are responses from correctly behaving mirrors: