Add support for Output Caching

[mkArtakMSFT]

Summary

Response caching is wrong, we wrote response caching people want output caching. We sniff headers when app want to say cache/nocache regardless of headers. 

It’s less customizable now that pubternal is gone

People with more context

@halter73, @Tratcher, @JunTaoLuo, @DamianEdwards

Motivation and goals

The existing response cache was designed to implement standard HTTP caching semantics. E.g. it cached based on HTTP cache headers like a proxy would (and may be useful in YARP). It also honors the client's request cache headers like using no-cache to bypass the cache.

An output cache is a different beast. Rather than checking HTTP cache headers to decide what should and should not be cached, the decision is instead made directly by the application, likely with a new request Feature, attributes, HttpResponse extension methods, etc. This cache also does not honor any request cache headers from the client. The client isn't supposed to know it's receiving a cached response.

We should create a new caching middleware that's explicitly designed for output caching. Leave the old one alone, it's fine for what it was designed for, but it doesn't cover the output cache scenarios. Trying to combine the two would just get messy, better to have a clean distinction. Note we can probably copy some of the infrastructure from the existing middleware around intercepting responses and storing them, but the public surface area will be fairly different.

There was one output caching style feature that was added to the response caching middleware later, that should be copied/moved(?). It's the VaryByQueryKeys feature on ResponseCachingFeature.

In scope

A list of major scenarios, perhaps in priority order.

Out of scope

Scenarios you explicitly want to exclude.

Risks / unknowns

How might developers misinterpret/misuse this? How might implementing it restrict us from other enhancements in the future? Also list any perf/security/correctness concerns.

Examples

Give brief examples of possible developer experiences (e.g., code they would write).

Don't be deeply concerned with how it would be implemented yet. Your examples could even be from other technology stacks.

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[stukselbax]

Recently I was asked to add response caching in our netcoreapp3.1 microservices using Redis as storage, and find out that there is no extension point to extend the ResponseCachingMiddleware behavior (changing storage, actually), and all similar issues links to this one.

What ResponseCachingMiddleware has (which we wouldn't want to duplicate) is:

• the logic to decide whether or not serve response from cache and whether or not response should be cached at all, which almost compliant with HTTP Caching
• response body sniffer (recently rewritten to pipes, which is nice)
• internal abstractions which talks to each other

What ResponseCachingMiddleware should allow to do is (IMHO):

1. change backing store (the hacky solutions like this or that says that I'm not the only one who wanted this feature)
2. influence to the final decision whether or not serve response from cache and whether or not response should be cached at all
3. cache invalidation (could have, but the topic is too complex)

So, my suggestions are follows:

• Rewrite response caching abstractions in a way to allow at least 1-2 should have features (for example, change IResponseCache to asynchronous versions, add extensibility to decision making about response caching, so on)
• Expose new abstractions to public
• Profit.

I couldn't see the benefit you gain if you write brand new middleware.