fix(libutil/tarfile): normalize legacy HTTP Content-Encoding names

[lovesegfault]

Motivation

Nix failed to download files served with Content-Encoding: x-gzip
because libarchive doesn't recognize the legacy x-* compression
format names. Per RFC 9110 §8.4.1.3, HTTP recipients should treat
these as equivalent to their standard counterparts.

Adds normalizeCompressionMethod() to map legacy encoding names
before passing to libarchive:

• x-gzip → gzip
• x-compress → compress
• x-bzip2 → bzip2

Context

Fixes: #14324

---

Add 👍 to pull requests you find important.

The Nix maintainer team uses a GitHub project board to schedule and track reviews.

[xokdvium]

I think that what we should do is stop using strings to represent enumeration types. We confuse compression algorithm name used by libarxhive and our non-standard Content-Enxoding headers. Those need to become clearly separated

[Mic92]

I think that what we should do is stop using strings to represent enumeration types. We confuse compression algorithm name used by libarxhive and our non-standard Content-Enxoding headers. Those need to become clearly separated

you mean libarchive has enum types for compression?

[xokdvium]

libarchive has enum types for compression?

It doesn't unfortunately, but we really should have our own to wrap around libarchive.

[Ericson2314]

I agree that making our own enum sounds like the right call.

[tomberek]

Can refactor into enum in another PR.

[xokdvium]

Note that must only affect Content-Encoding parsing. e.g. it must not be possible to specify the deprecated name as the store parameter. Since there's currently no distinction in the code it's a no-go IMO.

[lovesegfault]

fwiw I agree the enum approach is better here, just haven't found the time to do it

[xokdvium]

just haven't found the time to do it

I have some WIP commits for that. In the meantime I don't see a need to rush. This (not accepting deprecated non-standard aliases) is not a regression.

[xokdvium]

I think this has been fully addressed with #15336.