Limit chained Content-Encoding decoders to 5

[Kludex]

A response can carry multiple Content-Encoding values, which we decode by building a MultiDecoder chain. Today that chain is unbounded - a response can list an arbitrary number of encodings and we'll happily build a decoder for each one.

Real responses apply one encoding, occasionally two. There's no legitimate reason to chain more than a handful, so this caps the chain at 5 and raises DecodingError past that.

The limit lives as a ClassVar on MultiDecoder so it stays easy to find and adjust.

AI Disclaimer

This PR was developed with the assistance of either Claude or Codex. I've reviewed and verified the changes.

[github-actions]

Docs preview:

[codspeed-hq]

Merging this PR will not alter performance

✅ 15 untouched benchmarks
⏩ 7 skipped benchmarks¹

---

_{Comparing limit-content-encoding-chain (dea9472) with main (873af0a)}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[cubic-dev-ai]

No issues found across 3 files

_{Re-trigger cubic}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0190de0d72

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Enforce the decoder limit before allocating children

Because this check runs only after _get_content_decoder() has already appended decoder_cls() for every supported Content-Encoding value, a response header containing thousands of gzip/deflate entries still allocates thousands of zlib decoder objects before this error is raised. That leaves the intended DoS guard largely ineffective for large but valid header blocks; the limit needs to be checked while parsing/counting encodings, before instantiating additional decoders.

Useful? React with 👍 / 👎.

[Kludex]

Good point - moved the check to count the parsed encodings before instantiating any decoders, so an over-long header is rejected up front. ef171fc

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 3 files (changes from recent commits).

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>