[HTTP interoperability] Bound stacked Content-Encoding chains without budget bypass

[seonghobae]

Buyer-visible gap

The current originweave-http first slice intentionally accepts at most one HTTP content coding (identity, gzip, or deflate). That is safe and explicit, but RFC 9110 permits an ordered list of content codings applied to a representation. A governed browser/runtime can therefore reject otherwise valid responses such as a representation encoded through two supported layers.

This is also a negotiation-consistency gap in the current first slice: request serialization advertises Accept-Encoding: gzip, deflate, while response decoding accepts either coding alone but rejects a second Content-Encoding member. This is fail-closed behavior, not an unsafe decoder bypass.

A fresh RFC 9110 review also found a narrower interoperability defect in the proposed repair contract itself: Content-Encoding uses the #content-coding list rule, and §5.6.1.2 requires recipients to parse and ignore a reasonable number of empty list elements. Therefore an implementation that categorically rejects empty comma members would be non-conforming. OriginWeave already bounds individual field values, field count, and the complete header section, so empty-element tolerance can remain linear and byte-bounded without turning an empty-member run into unbounded work.

This is an interoperability gap, not a claim that current #37 is protocol-unsafe. Keep #37/#9 bounded and mergeable; implement this only after the canonical HTTP authority is stable in its parent lineage or through an ordinary-forward successor that preserves every current test/evidence contract.

Standards / semantics authority

RFC 9110 defines Content-Encoding as #content-coding and states that codings are listed in the order in which they were applied. Decoding therefore proceeds in reverse application order. Repeated field lines with the same field name are combined in received order; the accepted coding chain must therefore preserve both field-line encounter order and comma-member order.

RFC 9110 §5.6.1.1 says senders MUST NOT generate empty list elements, but §5.6.1.2 separately says recipients MUST parse and ignore a reasonable number of empty list elements. Empty elements do not contribute to list cardinality. For this bounded client, non-empty content-coding count is therefore the depth authority; empty elements are ignored only within the already enforced header-value/header-section byte budgets and must not create decoder work. An all-empty Content-Encoding list has zero non-empty codings and is treated as no content coding, rather than as an unsupported coding token.

RFC 9110 reserves identity for its special role in Accept-Encoding and says it SHOULD NOT be included in Content-Encoding; a sole explicit identity may remain a compatibility leniency, but identity combined with another non-empty coding is not an admitted stack.

RFC 1952 permits gzip data as a concatenated series of members; that intra-gzip member rule is distinct from HTTP-level stacking. The existing raw RFC 1951 fallback for a single deflate layer is a separately evidenced compatibility path and must not become an unbounded retry mechanism inside a coding chain. RFC 9530 digest semantics remain bound to their current content/representation byte domains; adding coding layers must not silently move integrity verification to post-decoding bytes.

References:

• Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP semantics (RFC 9110; STD 97). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110
• Deutsch, P. (1996). DEFLATE compressed data format specification version 1.3 (RFC 1951). Internet Engineering Task Force. https://doi.org/10.17487/RFC1951
• Deutsch, P. (1996). GZIP file format specification version 4.3 (RFC 1952). Internet Engineering Task Force. https://doi.org/10.17487/RFC1952
• Polli, R., & Pardue, L. (2024). Digest fields (RFC 9530). Internet Engineering Task Force. https://doi.org/10.17487/RFC9530

Current RFC Editor metadata lists the RFC 1951/1952 author as P. Deutsch. IETF Datatracker synchronized that metadata on 20 May 2026; the immutable RFC text retains the historical full name “L. Peter Deutsch.” This provenance note prevents a metadata-normalization change from being mistaken for a standards or semantic change.

Ownership / DDD boundary

This remains inside OriginWeave HTTP semantics. It must not move content-decoding policy into Chromium, MCP/driver adapters, contextual-orchestrator, EgressWeave, Wardnet, or a model decision. Browser/domain policy continues to consume typed HTTP evidence; adapters do not mint success.

Model the accepted coding chain as a bounded value rather than an unbounded string list. Evidence must preserve the exact admitted wire-order coding sequence and each layer's actual decoder outcome without retaining response content.

RED → repair acceptance

1. Start with a realistic regression proving the current exact implementation rejects a standards-valid two-layer response composed only of already-supported codings. Use a real authenticated loopback TLS exchange, not only a unit fixture. The captured request must prove the client actually advertised Accept-Encoding: gzip, deflate before the test attributes buyer impact to negotiation inconsistency.
2. Use reviewed fixed/default max_content_coding_depth = 2 for this first slice while request serialization remains fixed to Accept-Encoding: gzip, deflate. Do not expose a caller-lowerable depth of 1 under that fixed advertisement. If a lower depth is required later, introduce one bounded accepted-coding/advertisement policy and derive both request advertisement and decoder admission from it, or narrow the request advertisement to one coding. A future increase above 2 is a separate resource/security decision.
3. Parse the complete repeated-field/combined field-value sequence first, preserving received field-line and member order in a bounded ContentCodingChain. Ignore empty list elements as RFC 9110 §5.6.1.2 requires, within the existing bounded header bytes; count only non-empty codings toward max_content_coding_depth. Reject unknown non-empty codings, mixed identity, and non-empty depth overflow before any decoder runs. Decode admitted layers in reverse application order. Preserve a sole explicit Content-Encoding: identity only as the existing compatibility behavior; an all-empty list is zero codings/no-op.
4. Enforce decoded-byte and expansion limits cumulatively across the complete chain. Every layer output must be checked against the original transfer-decoded coded-content byte count; a layer transition must not reset the ratio denominator or allow ratio^depth amplification. Use checked or fail-closed arithmetic and fail before observable success.
5. Preserve gzip multi-member semantics within a single gzip layer. Do not confuse concatenated RFC 1952 members with multiple HTTP content-coding layers.
6. Preserve the raw RFC 1951 DEFLATE fallback as a bounded compatibility decision for that exact layer only. Size/ratio failures must never trigger fallback, and nested-layer failures must not cause combinatorial retry paths.
7. Realistic hostile/interoperability cases must cover: valid gzip, deflate and deflate, gzip chains; the equivalent repeated-field-line form in encounter order; RFC 9110 empty-list-element tolerance such as gzip, , deflate, plus an all-empty list; malformed outer and inner layers; truncated members; trailing non-coding bytes; non-empty layer-depth overflow; cumulative expansion attack; zero-length input; and a chain containing an unsupported non-empty coding. Empty elements must not create decoder invocations or count toward depth.
8. Content-Digest/Repr-Digest semantics must remain code-current. In the current full-200 slice, integrity validation occurs on transfer-decoded, still-content-coded bytes before content decoding; stacked decoding must not silently move that byte-domain boundary or collapse distinct digest semantics into one generic post-decode result.
9. Evidence must retain the exact admitted wire-order chain of non-empty codings plus each layer's actual decoder outcome (standard or raw-DEFLATE compatibility where applicable). Audit evidence need not preserve ignored empty list syntax; wire-order semantics must never be reconstructed from the final decoder result.
10. Update ADR/design/doctoring/TRACEABILITY/CHANGELOG and the canonical product-gap baseline owner lane with problem, alternatives, selected limit, rejected alternatives, risk/effect, rollback and exact evidence. Keep ADR Proposed until exact-head repository/security/browser-relevant evidence exists.
11. Owned production rustdoc, unit/integration/edge-case coverage remain 100%; exact-head CI/SAST/Security/CodeQL and eligible independent review must execute. Queued/skipped/predecessor/status-only evidence is not acceptance.

Performance / resource contract

Measure the buyer path with representative compressed payloads. The implementation should stream layer output through bounded sinks rather than materialize an unbounded intermediate per layer. If the current Vec-based decoder is retained for the first repair, every intermediate remains bounded by the same decoded-content ceiling and the coarse strict-default payload-buffer peak is approximately 80 MiB: original coded body up to 16 MiB + one prior intermediate up to 32 MiB + one new output up to 32 MiB, excluding allocator, decoder and TLS overhead. Record that explicitly; do not call the first Vec-based implementation streaming.

Empty list-element handling must remain linear in already admitted header bytes and must not allocate or invoke a decoder per empty element. The existing per-field value, field-count, and complete-header-section budgets are the outer DoS bounds; if implementation profiling shows a separate list-element cap is required, add it as a named policy with a documented RFC 9110 “reasonable number” rationale rather than silently rejecting every empty element.

Non-goals

• adding Brotli or Zstandard in the same change;
• increasing current maximum encoded/decoded size or expansion ratio to make tests pass;
• changing transfer-coding support;
• connection pooling/reuse;
• browser rendering or file persistence;
• LLM/model adjudication of content safety;
• copying mutable source from another CWL owner.

Depends on the canonical HTTP authority tracked by #9/#37. Keep this issue open until stacked supported codings have exact-head realistic evidence and normal protected integration.

[seonghobae]

Test-first successor is now materialized as #327 on exact canonical HTTP parent #37 15e7c97dc1102934fa1e3ca8517b86938a808565.

Exact child head 6f9614513a1d5abce918739e52129dd9c8cfd7c7 adds only one realistic authenticated loopback TLS integration regression: the representation is encoded gzip first and then zlib-wrapped deflate, the wire advertises Content-Encoding: gzip, deflate, and the exchange must recover the original payload by decoding in reverse application order. The current parent select_content_coding rejects the second member, so this test mechanically targets the #326 interoperability gap without changing production semantics, policy limits, dependencies, workflows, or release surfaces.

Fresh CI run 35795592798 exists for the test-only head, but its Rust contracts 106974026475 and Production coverage 106974026446 are still pre-step queued with no runner/steps. No hosted RED is claimed yet. Keep #37 bounded and unchanged; #327 remains a stacked successor and must ordinary/non-force adopt any future accepted parent movement before production repair acceptance.

[seonghobae]

Implementation decision candidate while #327 RED waits for runner admission, derived from the current parent code rather than from a protocol-validity claim:

• Depth budget: use reviewed maximum/default max_content_coding_depth = 2 for this bounded successor. RFC 9110 permits a list but sets no product resource limit; two layers closes the concrete buyer gap with the smallest auditable expansion of authority. Callers may lower the budget to 1, never raise it above the reviewed maximum. A future depth increase is a separate resource/security decision.
• Value model: parse the complete field list first into a bounded wire-order ContentCodingChain; missing Content-Encoding remains identity/no transform. Preserve a sole explicit Content-Encoding: identity only as current compatibility behavior: RFC 9110 §8.4 reserves identity for its special role in Accept-Encoding and says it SHOULD NOT be included in Content-Encoding. Reject identity combined with any other member, empty members, unknown codings, and depth overflow before any decoder runs. Repeated gzip/deflate are not rejected merely for repetition because RFC 9110 allows codings to be listed in application order; the depth budget is the controlling product bound.
• Decode order: iterate the admitted chain in reverse wire order. Raw RFC 1951 compatibility is an outcome of one deflate layer, not a wire coding and not a second candidate branch after a size/ratio failure.
• Cumulative budget: every layer output is checked against the original transfer-decoded coded-content byte count, not the preceding layer length. Therefore the existing decoded-byte ceiling and expansion ratio cannot reset at a layer boundary or compound as ratio^depth.
• Evidence: retain the exact wire-order admitted coding list plus each layer's actual decoder outcome (standard vs raw-DEFLATE compatibility). Do not infer wire order later from the final decoder result. RFC 9110 §§8.1 and 8.4 define representation metadata, including Content-Encoding, against the coded form. RFC 9530 §§2-3 keeps Content-Digest/Repr-Digest tied to HTTP content/representation semantics; current OriginWeave validates those integrity fields on the transfer-decoded, still-content-coded bytes before content decoding. Stacked decoding must not silently move that byte-domain boundary.
• Memory bound for the first repair: if the current Vec-based decoder is retained, enforce the same cumulative 32 MiB decoded ceiling for every intermediate. With the existing 16 MiB encoded ceiling, the current exchange retaining the original coded body plus one prior intermediate plus one new output has a coarse worst-case payload-buffer bound of about 80 MiB (16 + 32 + 32 MiB), excluding allocator/decoder/TLS overhead. Record that explicitly rather than calling the path streaming. A later streaming pipeline can reduce peak memory without changing the chain contract.

Primary standards authority:

• Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP semantics (RFC 9110; STD 97). Internet Engineering Task Force. https://doi.org/10.17487/RFC9110
• Polli, R., & Pardue, L. (2024). Digest fields (RFC 9530). Internet Engineering Task Force. https://doi.org/10.17487/RFC9530

Rejected for this successor: unbounded RFC-list depth; per-layer ratio reset; ratio^depth allowance; treating gzip members as HTTP coding layers; trying both raw/zlib decoders after a resource-limit error; and changing digest validation to post-decoding bytes.

This remains Proposed until the exact test-only #327 head executes the realistic RED. No production change should be accepted from this comment alone.

[seonghobae]

#327 test-only head advanced ordinary-forward to 64f9e4ebaea15b245d41b27c7092d1a80fc12ff4 before accepting any RED. The only added delta tightens fixture causality: join and propagate the TLS server result, prove the exact GET request reached that authenticated peer, distinguish the expected UnsupportedContentCoding rejection from unrelated setup/network failures, and keep desired success as the test oracle. New native CI is 35796140817, currently nonterminal; predecessor queued evidence does not transfer. Production code remains untouched.

[seonghobae]

Fresh parent-source audit on #37 exact 15e7c97dc1102934fa1e3ca8517b86938a808565 narrows the implementation shape before #327 leaves RED:

• HttpPolicyLimits / HttpClientPolicy currently have encoded-byte, decoded-byte and expansion-ratio budgets but no coding-depth budget. Add max_content_coding_depth to the named limits path and immutable HttpResourceBudgets; strict_defaults() should use the reviewed value 2. Keep the existing positional compatibility constructor from gaining another same-typed argument: it can delegate with the reviewed default, while callers that need depth 1 use from_limits. This avoids creating a new parameter-transposition hazard merely to expose the bound.
• DecodedContent and HttpExchangeEvidence currently collapse decoding to one ContentCoding, and content_coding() returns that single value. That cannot truthfully represent gzip, deflate plus a layer-local raw-DEFLATE compatibility outcome. The repair therefore needs a bounded typed per-layer evidence value in wire order, with decoder outcome separate from the wire coding. Do not reconstruct a chain from the final decoder result.
• decode_reader currently receives the current input length as the expansion denominator. Reusing it naïvely per layer would reset the ratio at each transition. The chain implementation must carry the original transfer-decoded coded-content length into every layer limit check; current-layer length may still be used for decoder/trailing-byte mechanics, but not as the cumulative expansion denominator.
• RFC 9110 §8.4 also says identity is reserved for its special role in Accept-Encoding and SHOULD NOT appear in Content-Encoding. The parent currently accepts a sole explicit Content-Encoding: identity; retaining that behavior in this successor is therefore a deliberate compatibility leniency, not a standards requirement. Mixed identity chains remain fail-closed as already planned and the doctoring/ADR must make this distinction explicit.

This is an API/resource-model finding from current source plus current RFC authority, not permission to skip the realistic RED. #327 exact 64f9e4ebaea15b245d41b27c7092d1a80fc12ff4 remains test-only until its current native run executes the intended parser rejection.

[seonghobae]

Fresh RFC 9110 review adds one parser/evidence acceptance detail without changing the live #327 test-only head.

Content-Encoding is a list-valued field. RFC 9110 §§5.2–5.3 permits repeated same-name field lines where the field definition allows a list, requires combination in received order, and makes that order significant; §8.4 then defines content codings in application order. Therefore the bounded ContentCodingChain must preserve one canonical encounter order across both comma-separated members and repeated Content-Encoding field lines. The depth budget applies to that combined sequence, not independently per field line.

Implementation/test consequence after the existing realistic #327 RED is actually observed:

• Content-Encoding: gzip, deflate and two received lines Content-Encoding: gzip followed by Content-Encoding: deflate must produce the same admitted wire-order chain and decode deflate then gzip.
• Reversing the received field-line order is semantically different and must preserve/reverse that different chain rather than sort or normalize it.
• Empty/unsupported/mixed-identity members and depth overflow must fail during complete-chain admission before any decoder runs, including when the invalid/depth-crossing member occurs on a later repeated field line.
• Evidence must retain the admitted combined wire-order chain, so replay/audit does not depend on reconstructing how field lines happened to be split.

This closes a standards-coverage gap in the proposed design; it does not claim a new source defect beyond #326, does not supersede #327 exact 64f9e4ebaea15b245d41b27c7092d1a80fc12ff4, and does not justify production implementation before that realistic test receives an executable hosted RED.

Primary authority: Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP semantics (RFC 9110; STD 97), §§5.2, 5.3, 8.4. Internet Engineering Task Force. https://doi.org/10.17487/RFC9110

[seonghobae]

Fresh RFC 9110 + current-parent audit tightens the severity/acceptance boundary without widening #327.

The first slice is not merely passively missing a standards-valid representation form. request.rs currently emits Accept-Encoding: gzip, deflate on every supported GET/HEAD request, while content.rs::select_content_coding accepts either coding alone but rejects any second Content-Encoding member. RFC 9110 §12.5.3 says Accept-Encoding identifies response content codings acceptable to the user agent and explicitly notes that a representation can carry multiple content codings; §8.4 requires those applied codings to be listed in application order. A server can therefore return a two-layer representation composed entirely of codings OriginWeave advertised as acceptable, and the current parser will fail closed on that response. This remains an interoperability/negotiation-consistency defect rather than an unsafe decode, but it is buyer-visible capability over-advertisement and strengthens the case for #327.

Acceptance consequence: keep the existing realistic gzip, deflate TLS RED, but treat its desired GREEN as restoring consistency between the fixed request advertisement and the bounded decoder. Do not widen the advertisement or add new codings. If the eventual implementation cannot satisfy the bounded chain contract, the safe fallback would be to narrow Accept-Encoding rather than keep advertising a coding combination the client cannot consume.

A second standards distinction should remain explicit in the repair. RFC 9530 defines Content-Digest over HTTP message content and Repr-Digest over selected representation data; they are different semantic targets even though, for this first slice's complete 200 response, both can legitimately be verified over the same transfer-decoded, still-content-coded byte sequence. Current integrity.rs already limits Repr-Digest verification to status 200 without Content-Range and marks unsupported contexts rather than guessing representation bytes. Stacked decoding must preserve that ordering and must not collapse the two digest concepts into a new generic post-decode digest field. HEAD/no-content remains an explicitly unsupported verification context for this implementation, not evidence that an empty body is the selected representation.

Parent #37 subsequently received executable CI and exposed a rustfmt-only failure. Its canonical artifact was applied verbatim as ordinary-forward 7007140e95f94d1601259384bf646b8bde6a240c, and #327 adopted that repaired parent non-force. Current test-only #327 is therefore exact b7e056a781297d570c908710737028ecd8ed5abd; fresh compare against parent is 3 commits ahead / 0 behind with exactly one changed file, the +229 integration regression. New exact CI 35804887882 is live. No production/source decoding mutation is justified until that generation executes and yields the intended parser-attributable RED.

[seonghobae]

Fresh policy/negotiation review finds one inconsistency in the current Proposed #326 design before any production implementation.

The proposed max_content_coding_depth = 2 says callers may lower the depth to 1 via HttpPolicyLimits. However, current request.rs unconditionally emits Accept-Encoding: gzip, deflate; it is not policy-derived. RFC 9110 §12.5.3 defines those tokens as response content codings the user agent accepts and explicitly allows a representation to have multiple content codings, while §8.4 records those codings in application order. Therefore a depth-1 policy combined with the unchanged request serializer would intentionally advertise both gzip and deflate yet reject the standards-valid two-layer representation that #327 is meant to support. A depth limit alone cannot express “either gzip or deflate, but never both” in Accept-Encoding.

Acceptance repair: keep reviewed/default depth 2 for the fixed Accept-Encoding: gzip, deflate first slice. Do not expose a caller-lowerable depth of 1 unless request negotiation is also made policy-coherent. If lower depth is required later, add an explicit bounded accepted-coding/advertisement policy and derive both Accept-Encoding and decoder admission from the same immutable policy value; alternatively narrow the advertisement to one coding. Do not silently let max_content_coding_depth=1 recreate the current capability-over-advertisement defect.

This does not widen #327 or supersede its live test-only exact head b7e056a781297d570c908710737028ecd8ed5abd. It tightens the pending policy contract only; production Rust still waits for the existing authenticated TLS RED to execute.

Primary authority: Fielding, R., Nottingham, M., & Reschke, J. (2022). HTTP semantics (RFC 9110; STD 97), §§8.4, 12.5.3. Internet Engineering Task Force. https://doi.org/10.17487/RFC9110

[seonghobae]

Test-first successor #327 advanced ordinary-forward to exact e93020a79b9acd300f8fbb9e2a6800f82348219c on unchanged canonical parent #37 7007140e95f94d1601259384bf646b8bde6a240c.

The realistic TLS RED now proves both sides of the buyer-facing negotiation inconsistency before accepting the parser failure: (1) the peer receives the exact expected GET request and (2) that captured request contains exact Accept-Encoding: gzip, deflate. It then serves the standards-valid two-layer Content-Encoding: gzip, deflate representation and still expects the current single-coding parser to fail at UnsupportedContentCoding until the eventual bounded repair.

This closes a missing-fixture gap only; production code, policy budgets, evidence types, workflows, rulesets, and release surfaces are unchanged. The first-slice policy remains fixed/default depth 2 while request advertisement remains fixed to both codings; the earlier issue-body sentence allowing callers to reduce depth to 1 is superseded by the later negotiation-consistency decision and must not be used as implementation authority.

Fresh exact CI 35812952026 exists but is currently pre-step queued, so no hosted RED or GREEN is claimed yet.

[seonghobae]

Current implementation lineage update for the stacked Content-Encoding gap: parent #37 advanced by a real hosted strict-Clippy repair to exact 219b43bfa87ab4fd90a77bb962df2797925bf661; child #327 was adopted ordinary/non-force to exact beabc7d3e27c5c407d2847ff179eb16682ad86cd.

Fresh compare parent -> child is 5 ahead / 0 behind with merge base equal to the current parent. The aggregate child delta is still exactly crates/originweave-http/tests/content_coding_stack_integration.rs (+235/-0), so none of the bounded production design in this issue has been implemented early. Current child CI 35816779893 is fresh and non-terminal. The required next causal transition remains executable authenticated-TLS RED on this exact test-only head before adding the bounded depth-2 decoder/evidence implementation.

[seonghobae]

#327 advanced ordinary-forward to exact 3d1409ec34a08518ecc7d215132faffeb855a903 without changing production HTTP semantics. The delta repairs CodeRabbit's current pre-merge documentation finding on the test-only lane: its summary reported 10% docstring coverage across the 10 touched functions, so all ten fixture/test functions now carry invariant-focused rustdoc covering fixture-only trust, pinned certificate validity, HTTP/1.1 ALPN, request capture, loopback authorization, authenticated TLS, coding construction, and the negotiation/decode-order oracle. Fresh compare to parent #37 219b43bfa87ab4fd90a77bb962df2797925bf661 is 8 ahead / 0 behind and still one added integration-test file only (+269 / -0).

Fresh exact CI is 35825132181; Rust contracts 107065098376 and Production coverage 107065098532 are pre-step queued with no assigned runner and steps=[]. No hosted UnsupportedContentCoding RED or current-head GREEN is claimed yet, and production stacked decoding remains intentionally unimplemented until that executable RED exists.

[seonghobae]

Current executable RED authority — exact c1b4f7a66c32d86ac8623cc10a3d0315cc72d74e on #327.

The RFC 9110 empty-list-element correction is now represented in the real authenticated loopback-TLS fixture, not only in this issue's acceptance prose. The one-file/test-only successor covers three wire cases under the same destination/TLS/ALPN/request-capture boundary: ordinary Content-Encoding: gzip, deflate, Content-Encoding: gzip, , deflate,, and all-empty Content-Encoding: , ,. The latter two require empty list elements to contribute zero coding depth and the all-empty form to leave content unchanged. Every fixture still proves exact request-side Accept-Encoding: gzip, deflate before attributing the RED to response coding semantics.

No production HTTP code changed. Exact CI 35836393281 is live with Rust contracts 107100775129 and Production coverage 107100775393 pre-step queued; predecessor results are not transferable. Production stacked decoding remains blocked on an executable hosted RED from this exact lineage.

[seonghobae]

Current executable-test authority update: exact 906a6170cda8ad2874f6ba04467a4aaf8a5e784f closes a fixture gap in #327. The acceptance contract already required repeated Content-Encoding field lines to preserve encounter order, but predecessor c1b4f7a... exercised only one field line with comma-separated members. 906a6170... changes only the existing authenticated-loopback-TLS integration test: the fixture can now emit ordered Content-Encoding field lines and adds Content-Encoding: gzip followed by Content-Encoding: deflate over the same gzip→deflate wire body, while still proving the request advertised Accept-Encoding: gzip, deflate. Production Rust remains untouched. New exact CI is 35842276629; Rust contracts 107119933463 and Production coverage 107119933970 are queued/nonterminal, so the intended hosted RED has not yet been observed and no decoder repair is claimed.