Support HttpApplication vary-by

[twsouthwick]

This change adds HttpApplication.GetVaryByCustomString(context, string custom). This API allowed for custom vary by strings given a custom key.

In order to connect that into ASP.NET Core 7+, we can use output caching. To enable this, a selector is required to allow the end user to identify what keys are to be used. For example, on ASP.NET Framework, attributes were used, so on ASP.NET Core a user can grab those attributes from the endpoint metadata collection and collect the keys that way.

For example, they can use the built-in browser custom string:

builder.Services.AddOutputCache(options =>
{
    options.AddHttpApplicationBasePolicy(_ => new[] { "browser" });
});

Fixes #316

[twsouthwick]

@Tratcher This is an API Sharepoint is using (see linked issue) and this looks to be the best way to hook it up. However, I hit an issue with the OutputCacheOptions APIs:

• There is no way to add a list of "vary-by" key/value pairs; only single items is supported
• There is no way to add a IOutputCachePolicy to a OutputCachePolicyBuilder - only by Type is supported. The API to add an instance method is internal for some reason

I worked around this by providing an API to add to the base policy or create a named policy. If there's a way to support the above that would probably make this a bit clearner.

[twsouthwick]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[twsouthwick]

@sebastienros The output caching related code is here. Any thoughts on better ways to connect this up would be appreciated.

[sebastienros]

Ack

[sebastienros]

LGTM

There is a VaryByValue() on the OutputCachePolicyBuilder in case that helps. You can invoke it as many times as you need. I assume it could take a list too (needs an issue to go through api-review).

The fact that you can't pass an instance is probably due to good reasons after talking about it in api-review because I am pretty sure it was possible until some point. Maybe it didn't seem useful to have this.

[twsouthwick]

Thanks @sebastienros. Looking at the history of the reviews, it looks like the overload to pass an instance to the builder was due to worry about recursion and not knowing if there was a use case.

There is a VaryByValue() on the OutputCachePolicyBuilder in case that helps. You can invoke it as many times as you need. I assume it could take a list too (needs an issue to go through api-review).

I've added an overload that now that uses that as well. I don't have a feel for what is the better way to set this up - hard coded keys up front, or querying the endpoint for metadata and extracting keys from the current endpoint. Being able to add a policy enables the second point (which is why I went that route initially), but maybe it's sufficient to define a policy with a hard coded list up front.

[twsouthwick]

@Tratcher any additional thoughts here?