I was trying to build some old software and noticed that Nix has trouble downloading files served with Content-Encoding: x-gzip.

$ nix store prefetch-file --unpack 'https://web.archive.org/web/20120531050718/http://www.mit.edu/~ibaran/kseg-latest.tar.gz'
error: failed to get libarchive filter by name: No such filter 'x-gzip'

The relevant HTTP headers for this URL are (note that web.archive.org is only reproducing the original Content-Type and Content-Encoding headers from 2012)

$ curl -IH 'Accept-Encoding: *' 'https://web.archive.org/web/20120531050718/http://www.mit.edu/~ibaran/kseg-latest.tar.gz'
# ...
content-type: application/x-tar
# ...
content-encoding: x-gzip
# ...

Nix directly passes the value of the Content-Encoding header to libarchive as part of the download, but libarchive does not support the legacy x-* variants that are recommended for HTTP recipients ("a recipient should consider "x-gzip" to be equivalent to "gzip").

(Taking the HTTP response at face value, the file at this .tar.gz URL is actually an uncompressed .tar file. Nix appears to handle this case just fine as long as Content-Encoding is something it supports, like plain gzip.)

Proposed solution

I don't think libarchive makes the claim that it knows how to map HTTP Content-Encodings to decompressors. I think Nix should take the responsibility of mapping Content-Encodings to libarchive decompressor( name)s, and in that mapping it should support x-gzip as an alias of gzip.

Alternative solutions

It would also be possible to say that libarchive should understand x-gzip for gzip, that an issue should be opened there, and that Nix shouldn't change anything except update to a libarchive that supports x-gzip.

Checklist

• checked latest Nix manual
• checked open feature issues and pull requests for possible duplicates