Accept transfer codings with parameters in Transfer-Encoding

[ericmj]

A Transfer-Encoding value with a parameter, such as "custom; level=1, chunked", failed with {:invalid_token_list, value} because the value was parsed as a plain list of tokens. RFC 9110 10.1.4 allows parameters on a transfer coding, as a token or a quoted string.

Transfer-Encoding values are now parsed with their parameters and only the coding names are kept, so the final coding of a response still decides between chunked framing and reading until close. The chunked coding defines no parameters and RFC 9112 7.1 says their presence should be treated as an error, so chunked with parameters is still rejected.

The same parser checks the Transfer-Encoding headers passed to request/5 with a streamed body and no Content-Length, so a value such as "gzip;q=1" is accepted there. The fields are combined with ", " into one value before parsing (RFC 9110 5.3). If chunked or identity is among the codings the headers are sent unchanged, as before. Otherwise chunked is appended to the last field, so it ends up as the final coding once.

[coveralls]

Coverage Report for CI Build 96

Coverage decreased (-0.05%) to 90.46%

Details

• Coverage decreased (-0.05%) from the base build.
• Patch coverage: 39 of 39 lines across 2 files are fully covered (100%).
• 6 coverage regressions across 3 files.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

6 previously-covered lines in 3 files lost coverage.

File	Lines Losing Coverage	Coverage
lib/mint/core/headers.ex	3	78.95%
lib/mint/http2.ex	2	95.28%
lib/mint/http1/response.ex	1	96.05%

---

Coverage Stats

Relevant Lines:	2002
Covered Lines:	1811
Line Coverage:	90.46%
Coverage Strength:	708.15 hits per line

---

💛 - Coveralls