Enable SocketHttpHandler to decompress zlib or deflate

[stephentoub]

Some servers incorrectly implement the deflate content-coding with the raw deflate algorithm rather than with deflate wrapped with a zlib header/footer. Auto-detect whether to use ZLibStream or DeflateStream in order to accomodate both kinds of responses.

Fixes #57604

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Some servers incorrectly implement the deflate content-coding with the raw deflate algorithm rather than with deflate wrapped with a zlib header/footer. Auto-detect whether to use ZLibStream or DeflateStream in order to accomodate both kinds of responses.

Fixes #57604

Author:	stephentoub
Assignees:	-
Labels:	area-System.Net.Http
Milestone:	6.0.0

[geoffkizer]

Should we have a test specifically for 0-length compressed content? Presumably this will always fail, but given that we need to special case this now (to peek at the first byte), should we validate that we fail as expected?

[stephentoub]

Should we have a test specifically for 0-length compressed content? Presumably this will always fail, but given that we need to special case this now (to peek at the first byte), should we validate that we fail as expected?

Suggestions for what specifically to test? Before and after this change, if there's a 0-length response body, either with Content-Length: 0 or with just closing the connection, the request succeeds.

[geoffkizer]

Suggestions for what specifically to test? Before and after this change, if there's a 0-length response body, either with Content-Length: 0 or with just closing the connection, the request succeeds.

Meaning, the response stream has 0 bytes? I suppose we could test for that.

Edit: I really meant "response stream" here, meaning the response content as reported to the user. Not "response body" as in bits on the wire.

[stephentoub]

I really meant "response stream" here, meaning the response content as reported to the user. Not "response body" as in bits on the wire.

I added a test for an empty response body, which translates to an empty pre-decompression response stream, which translates to an empty post-decompression response stream.

I can add a test as well for a non-empty response body that translates to a non-empty pre-decompression response stream that translates to an empty post-decompression response stream... is that what you mean?

[stephentoub]

/backport to release/6.0-rc1

[github-actions]

Started backporting to release/6.0-rc1: https://github.com/dotnet/runtime/actions/runs/1159222795