fix: decode multiple Content-Encoding codings in reverse order (RFC 9110) - #13377
fix: decode multiple Content-Encoding codings in reverse order (RFC 9110)#13377waterWang wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #13377 +/- ##
========================================
Coverage 98.98% 98.99%
========================================
Files 132 132
Lines 49023 49297 +274
Branches 2551 2568 +17
========================================
+ Hits 48526 48802 +276
+ Misses 373 371 -2
Partials 124 124
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. |
Merging this PR will not alter performance
Comparing Footnotes
|
Summary
RFC 9110 §8.4 allows
Content-Encodingto list multiple codings. The client must decode them in reverse order. When a server sends a body compressed twice withContent-Encoding: gzip,gzip, aiohttp currently does not decode the body because the header value"gzip,gzip"does not match the single-coding set{"gzip", "deflate", "br", "zstd"}.Changes
HttpParser.parse_headers()— ParseContent-Encodingas a comma-separated list. Validate each coding individually and store the normalized list as a comma-separated string (e.g.,"gzip,gzip").HttpPayloadParser.__init__()— Chain multipleDeflateBufferinstances in reverse order so each coding is decoded in the correct sequence (last applied first).DeflateBuffer.__init__()— Forward_low_waterfrom the wrapped stream to support safe chaining ofDeflateBufferinstances.Testing
Expected:
{"hello": "world"}when the endpoint sendsContent-Encoding: gzip,gzipwith a doubly-gzipped JSON body.Fixes #13364