Request.Body is not decompressed when Content-Encoding: gzip, even with ASP.NET Core’s UseRequestDecompression()

[slipdef]

Package

Sentry

.NET Flavor

.NET Core

.NET Version

9.0.6

OS

Windows

OS Version

11

Development Environment

Visual Studio v17.x

SDK Version

3.23.1

Self-Hosted Sentry Version

No response

Workload Versions

---

aspire 8.2.2/8.0.100 VS 17.14.36212.18

When using Sentry SDK in an ASP.NET Core app with UseRequestDecompression(), HTTP requests with Content-Encoding: gzip are still logged with their raw compressed body in Sentry.

This occurs because UseRequestDecompression() only integrates with model binding and does not replace or decompress HttpContext.Request.Body, which Sentry reads directly.

Steps to Reproduce

Configure ASP.NET Core pipeline with UseRequestDecompression() early.

Enable Sentry automatic request body logging.

Send a POST request with Content-Encoding: gzip and gzipped JSON body.

Trigger an exception.

Check Sentry issue – Request.Body is unreadable gzip binary.

Expected Result

Sentry should log the decompressed request body when UseRequestDecompression() is enabled and the request has Content-Encoding: gzip.

Actual Result

[jamescrosswell]

Thanks for reporting this @slipdef . I can reproduce it.

I think ultimately it's a result of Sentry's middleware being called before the RequestDecompressionMiddleware so the HttpContext.Request.Body is still compressed in the version of things that Sentry is looking at. We even have a StartupFilter to ensure that Sentry is the first middleware to be registered in the chain.

Ideally this would "just work" from an SDK user's perspective.

We could achieve that by adding the RequestDecompressionMiddleware before registering Sentry's middleware. I'm not sure if people would want this to be "always on" however... that might cause unintended side effects for some folks.

Another option would be to check whether IRequestDecompressionProvider has been registered in the services collection. Only if it has would we register the RequestDecompressionMiddleware before Sentry's middleware when initialising Sentry. As a safeguard, we could add an option like AutoRegisterRequestDecompressionMiddleware to SentryAspNetCoreOptions to make it possible to disable this logic if you really wanted to. Maybe we add this only if people request it - seems like it's solving a hypothetical problem at the moment.

It would be possible to add a wrapper around the app builder to prevent re-registrations of the RequestDecompressionMiddleware as well (similar to what we do for tracing).

I'll put a PR together for this ASAP.