Introduce a depth limit of nested content encodings

[starrify]

What problem are you trying to solve?

This spec, together with some common HTTP client implements, allow nested content encodings. E.g. a web server may send content-encoding: br, gzip, br, gzip while compressing the body stream accordingly.

This spec does not impose any constraint on the depth of nested content encodings, and this ticket proposes to introduce one that is reasonably low, e.g. 10.

Relevant sections:

• In the currently rendered spec, section 4.7. HTTP-network fetch, step 18.
• In the current revision of the draft file 2025-12.bs, at around line 6760

What solutions exist today?

Seems none in this spec.

By the way, here are the behaviors of a few implements:

• Chromium: There is no explicit constraint. Thus the depth is implicitly limited by the allowed size of HTTP response headers. E.g. for HTTP/1.1 Chromium has a header read buffer of 256 KB, thus a web server may be able to request up to 87k nested decoders (e.g. content-encoding: br,br,br,br,br,...<87k "br,"s>...,br). An issue has been reported, and a fix proposed to set a limit of 10.
• Firefox: The implement accepts up to 16 nested decoders, and ignores the rest by sending the remaining stream as-is (code).
• curl/libcurl: Accepts up to 5 nested decoders, and raises an error to abort the response if exceeded (code).

How would you solve it?

To explicitly set an upper limit, e.g.:

-If codings is null or failure, then set filteredCoding to the empty string.
+If codings is null or failure, or if codings's size is greater than 10, then set filteredCoding to the empty string.
 Otherwise, if codings’s size is greater than 1, then set filteredCoding to "multiple".

Anything else?

No response