[wtgodbe]

On IIS out-of-process hosting, IISMiddleware cleared the request body size limit (MaxRequestBodySize = null). RequestDecompressionMiddleware consumed that as an unbounded decompressed-body budget, allowing an anonymous decompression-bomb DoS (temporary, with amplification).

Gate the null-assignment behind the Microsoft.AspNetCore.Server.IISIntegration.ClearMaxRequestBodySize AppContext switch (default off). By default the server request body size limit is preserved; apps needing the legacy defer-to-IIS behavior can opt in.

Prevents unbounded request-body decompression on IIS out-of-process. Opt-out switch provided for compatibility.

[Copilot]

🟡 Changes recommended

The new switch-controlled behavior isn’t fully covered by tests (the opt-in path and the “feature absent” case under the opt-in switch need explicit coverage and isolation).

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR addresses a security/compatibility issue in IIS out-of-process hosting where IISMiddleware previously cleared IHttpMaxRequestBodySizeFeature.MaxRequestBodySize, which could be interpreted by request decompression as an unbounded decompressed-body budget. The change preserves the server-side limit by default and introduces an AppContext switch to opt into the legacy “clear the limit” behavior.

Changes:

• Gate clearing MaxRequestBodySize behind the Microsoft.AspNetCore.Server.IISIntegration.ClearMaxRequestBodySize AppContext switch (default: off).
• Add unit tests to validate the default behavior (do not clear) and basic behavior when the feature is absent.

File summaries

File	Description
src/Servers/IIS/IISIntegration/src/IISMiddleware.cs	Adds an AppContext switch-controlled opt-in path for clearing MaxRequestBodySize, preserving the configured limit by default.
src/Servers/IIS/IISIntegration/test/Tests/IISMiddlewareTests.cs	Adds tests around MaxRequestBodySize behavior and introduces test helpers for constructing an IISMiddleware instance and HttpContext.

Review details

Suppressed comments (1)

src/Servers/IIS/IISIntegration/test/Tests/IISMiddlewareTests.cs:560

• DoesNotThrowWhenMaxRequestBodySizeFeatureAbsent currently runs with the AppContext switch default (off), so it doesn't exercise the new guarded code path. Setting the switch to true for this test (and resetting it in a finally) ensures we cover the opt-in path where the feature lookup happens, while still validating it doesn't throw when the feature is missing.

    [Fact]
    public async Task DoesNotThrowWhenMaxRequestBodySizeFeatureAbsent()
    {
        var nextInvoked = false;
        var context = new DefaultHttpContext();

• Files reviewed: 2/2 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[rokonec]

The three WebSocketsOutOfProcessTests failures in the last CI run are a real regression from this change, not infrastructure flakiness. Fixed in befb2e9.

What failed

IIS.FunctionalTests and IISExpress.FunctionalTests, the same three tests in each:

• WebSocketsOutOfProcessTests.CanSendAndReceieveData
• WebSocketsOutOfProcessTests.OnStartedCalledForWebSocket
• WebSocketsOutOfProcessTests.WebReadBeforeUpgrade

The fix

Scope the assertion to in-process hosting, where it is meaningful:

if (context.Features.Get<IServerVariablesFeature>() is not null)
{
    Assert.Null(context.Features.Get<IHttpMaxRequestBodySizeFeature>().MaxRequestBodySize);
}

IISHttpContext implements IServerVariablesFeature; Kestrel does not. In-process coverage is unchanged, and no product code is touched.

[BrennanConroy]

/backport to release/10.0

[BrennanConroy]

/backport to release/9.0

[github-actions]

Started backporting to release/10.0 (link to workflow run)

[BrennanConroy]

/backport to release/8.0

[github-actions]

Started backporting to release/9.0 (link to workflow run)

[github-actions]

Started backporting to release/8.0 (link to workflow run)