Background and Motivation

When designing intranet based web enabled database systems, which always require authorization and are accessed from secure company computers using an internal IP address, it would greatly enhance speed to be able to cache some page content. There are often long lists of data, frequently 10+Mb of data, that changes infrequently and must currently be added to every page load. Sometimes these apps are used remotely over a slow VPN connection.
This change would give developers the choice to cache content data.

An alternative that may be suggested is AJAX partial loading, however this is not much more efficient and on slow connections can severely affect responsiveness. The best model IMO is one that has a long initial page load, but then only short delays for small AJAX payloads and short subsequent page loads, ie. cached data.

At the moment, the only option to achieve this in DotNet is to mod up a custom version of the middleware, which is surely far more fraught.

Proposed API

namespace Microsoft.AspNetCore.ResponseCaching;

public class ResponseCachingOptions
{
+    /// <summary>
+    /// <c>true</c> if caching is allowed for authorised endpoints
+    /// </summary>
+    public bool AllowAuthorizedEndpoint { get; set; } = false;
}

Usage Examples

In Startup.cs:

public void ConfigureServices(IServiceCollection services) {
  ...
  services.AddResponseCaching(options => { options.AllowAuthorizedEndpoint = true; });
  ...

}

Alternative Designs

None. This proposal simply exposes a new member to enable missing functionality.

Risks

There are no explicit risks. It is a non breaking change, and as such the new option defaults to existing behaviour and does not need to be specified.

In terms of implicit risk, the reason that has been given re the lack of configurability to date around authorized endpoints is that cached authorized data is a security risk. I would argue that while this is often the case, it is not always the case. The developer should be able to configure the framework so as to acheive their own desired balance of security, network performance and device CPU/resource loading.

To further protect cached data, it would also be possible to cache it in encrypted form and use javascript to decrypt before parsing to JSON, using an encryption key passed only with authorized page loads. This would sacrifice client CPU loading for network bandwidth, very likely a productive swap in terms of page load speed.

See PR to implement the full functionality: #56768