ResponseCompression tests should verify functionality, not exact compressed byte counts

[medhatiwari]

ResponseCompression tests fail with system zlib

Problem

45 tests fail on systems using system zlib instead of bundled zlib-ng:

Assert.Equal() Failure: Values differ Expected: 29 Actual: 30

at Microsoft.AspNetCore.ResponseCompression.Tests.ResponseCompressionMiddlewareTest.CheckResponseCompressed(HttpResponseMessage response, Nullable`1 expectedBodyLength, String expectedEncoding) in /_/src/Middleware/ResponseCompression/test/ResponseCompressionMiddlewareTest.cs:line 1303
at Microsoft.AspNetCore.ResponseCompression.Tests.ResponseCompressionMiddlewareTest.Request_AcceptGzipDeflate_CompressedGzip() in /_/src/Middleware/ResponseCompression/test/ResponseCompressionMiddlewareTest.cs:line 62

Root Cause

Different zlib implementations produce different but functionally equivalent output:

• zlib-ng: 29 bytes → decompresses correctly
• system zlib: 30 bytes → decompresses correctly

Both are RFC compliant. Tests check exact byte counts instead of functionality.

Solution

Replace byte count checks with decompression verification:

Current:

Assert.Equal(expectedBodyLength, response.Content.Headers.ContentLength);

Proposed:

var decompressed = await DecompressResponse(response);
Assert.Equal(expectedContent, decompressed);

Files

src/Middleware/ResponseCompression/test/ResponseCompressionMiddlewareTest.cs

cc: @giritrivedi @omajid @tmds

[MihuBot]

I'm a bot. Here is a possible related and/or duplicate issue (I may be wrong):

• ResponseCompressionMiddlewareTests failing in release/8.0 on Fedora41 #59870