resource-collection.xxxx.js gzip footer not passed

[ThibaultLesuisse]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We noticed that the resource-collection.x.js file misses the GZIP footer so that some decompression tools fail. GZIP itself returns "gzip: unexpected end of file". It could of course be that our setup is missing something and that the contents of resource-collection.x.js is corrupt because of this. I've checked with a few LLM's that tell me this could be a bug so here I am.

The CreateGzipBytes method does not properly write the GZIP footer because Dispose() on the GZipStream occurs after calling ToArray(). This means the output byte array is missing the footer, which results in incomplete or corrupted GZIP data. Behavior of the GZIP library is explained here dotnet-runtime

Code Location:
src/Components/Endpoints/src/Builder/ResourceCollectionUrlEndpoint.cs#L82

Current implementation:

private static byte[] CreateGzipBytes(byte[] bytes)
{
    using var gzipContent = new MemoryStream();
    using var gzipStream = new GZipStream(gzipContent, CompressionLevel.Optimal, leaveOpen: true);
    gzipStream.Write(bytes);
    gzipStream.Flush();
    return gzipContent.ToArray();
}

Expected Behavior

I expect the returned byte array to include the GZIP footer so it can be decompressed by clients.

The code should dispose/close the GZipStream (which writes the footer) before reading from the MemoryStream:

private static byte[] CreateGzipBytes(byte[] bytes)
{
    using var gzipContent = new MemoryStream();
    using (var gzipStream = new GZipStream(gzipContent, CompressionLevel.Optimal, leaveOpen: true))
    {
        gzipStream.Write(bytes);
    }
    return gzipContent.ToArray();
}

Steps To Reproduce

1. Setup a Blazor Web App
2. Make sure the Accept-Encoding Header is set to contain gzip
3. Use curl to manually fetch the resource-collection.xxxx.js file
4. use tar or gzip to check for the integrity of the file
5. tar -xzf .\output.gz results in tar.exe: Error opening archive: Unrecognized archive format

Optional: Compare byte output before/after switching disposal order.

Exceptions (if any)

No Exceptions

.NET Version

10.0.5

Anything else?

Duplicate of #66213 because I'm an idiot who closes issues too soon

[github-actions]

Triage Summary

Area: area-blazor — The bug is in src/Components/Endpoints/src/Builder/ResourceCollectionUrlEndpoint.cs, which is part of the Blazor/Components endpoints infrastructure (resource collection serving).

Type: bug — The CreateGzipBytes method reads the MemoryStream before disposing the GZipStream, so the GZIP footer (CRC32 + size) is never flushed into the output buffer. This produces invalid/truncated GZIP data that decompression tools reject.

Potential Duplicates

• GZipStream footer not written in CreateGzipBytes due to Dispose order #66213 - "GZipStream footer not written in CreateGzipBytes due to Dispose order" (similarity: high — identical issue, same code path, same fix proposed, same author; closed prematurely by the reporter themselves)

Notes

• The author explicitly acknowledges this is a re-open of GZipStream footer not written in CreateGzipBytes due to Dispose order #66213 which they closed too soon.
• The fix is straightforward: wrap the GZipStream in its own using block so it is disposed (and the footer written) before calling gzipContent.ToArray().
• No regression info provided — it's unknown whether this ever worked correctly; the feature may have shipped with this bug.

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66218 · ● 168.4K · ◷