Fix OutputCache caching truncated responses for aborted requests

[Bellambharath]

Fixes #66877

Problem

OutputCacheMiddleware can cache an empty or truncated response when the request that populates the cache is canceled. The broken entry is then served to all subsequent clients until it expires.

This happens because the existing cacheability checks have two blind spots:

The Content-Length check is bypassed when the header is absent (e.g. ResponseCompression removes it).

A decorator stream layered above OutputCacheStream (e.g. GZipStream) can throw OperationCanceledException before the write reaches OutputCacheStream, so BufferingEnabled stays true even though the body is incomplete.

The locking path (SetLocking(true)) has an additional issue: concurrent requests waiting on the in-flight response are served directly from the OutputCacheEntry returned by ExecuteResponseAsync, bypassing the normal cacheability checks entirely.

Fix

Two targeted changes to OutputCacheMiddleware.cs:

1. FinalizeCacheBodyAsync — skip storing if RequestAborted is canceled:

// Do not cache a response whose originating request was aborted.
if (context.HttpContext.RequestAborted.IsCancellationRequested)
{
    _logger.ResponseNotCached();
    return;
}

This is the right place because it is the single choke-point before every StoreAsync call. RequestAborted being canceled at this point is a strong, observable signal that the response body is incomplete — it is the token passed to WriteAsync in virtually every IActionResult implementation, and callers are expected to call httpContext.Abort() after catching OperationCanceledException mid-write.

2. ExecuteResponseAsync (locking path) — return null if the request was aborted after _next completes:

if (httpContext.RequestAborted.IsCancellationRequested)
{
    _logger.ResponseNotCached();
    return null;
}

Returning null here causes TryServeCachedResponseAsync to short-circuit, so no truncated entry is handed off to waiting concurrent requests.

Testing

The existing test FinalizeCacheBody_Cache_IfContentLengthAbsent and the locking tests continue to pass unchanged. The repro from the issue (OutputCache + ResponseCompression, client cancels after 1 s, subsequent request should get full payload) is the end-to-end verification scenario.

[dotnet-policy-service]

Thanks for your PR, @Bellambharath. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[BrennanConroy]

There should be a test or 2 here. Aborting the request in the middle of writing a response and seeing that future requests don't get the truncated response, and making sure the aborted request doesn't re-run the request pipeline.

[BrennanConroy]

We should be setting executed = true; here so the aborted request doesn't try to serve a cached response or re-run the request pipeline.

[BrennanConroy]

@Bellambharath are you interested in continuing with this contribution?

[DeagleGross]

Thanks for contribution @Bellambharath; we have an active PR solving same issue here: #68683.
Closing this one