Concatenated gzip responses fail since 0.6.8

• I have looked for existing issues (including closed) about this

Bug Report

Version

tower-http 0.6.11 (also 0.7.1)

Platform

Darwin 27.0.0 arm64, and ubuntu-latest in CI

Crates

tower-http (decompression-gzip)

Description

#621 dropped multiple_members from the gzip decoder and deleted decompress_multi_gz. Kubernetes
1.37 now emits exactly that shape: its watch compression closes the gzip stream on every flush, so a
compressed watch stream is one complete gzip member per event, and decoding stops after the first
with there are extra bytes after body has been decompressed. Go and curl decode it, and RFC 9110
defines the gzip coding by reference to RFC 1952, which allows a member sequence. reqwest is affected
too since it delegates decompression here.

I am not asking for a straight revert. I re-enabled multiple_members locally against
async-compression 0.4.47 and test_chunked_fragmented_response_with_extra_bytes still hangs, so #621
is still doing real work. The cause is narrower than the flag: the gzip header magic is only checked
once 10 bytes are buffered, so trailing garbage shorter than that stalls instead of erroring. Filed
upstream as https://github.com/Nullus157/async-compression/issues/488. Once that lands, is
re-enabling multiple_members here something you would take, or would you rather expose it as an
opt-in on DecompressionLayer?

Meanwhile we send Accept-Encoding: identity on watch requests (kube-rs/kube#2080).

Start in the tower-http decompression-gzip implementation and run test_chunked_fragmented_response_with_extra_bytes, then review the effect of async-compression 0.4.47 and upstream issue #488. Done requires a decided handling for concatenated gzip members in DecompressionLayer without regressing the extra-bytes case, with the affected test behavior verified.