[HttpClientFactory] Add support for client-side cache-control

[dotMorten]

In .NET Framework it was possible to specify that web requests should use the shared browser cache by setting:
myWebRequestHandler.CachePolicy = new System.Net.Cache.RequestCachePolicy(System.Net.Cache.RequestCacheLevel.Default);

This allows repeated web requests to either be pulled from the local browser cache (if not expired) or do much faster ETag 304 requests/response. This is really really useful for client apps that frequently check for status updates in a resource, image tile requests etc, and can reduce the network overhead tremendously.

For example I made a (very) quick and dirty cache implementation showing a 33x perf increase on repeated requests when implementing cache-control max-age and/or etag:

Method	Mean	Error	StdDev	Median	Ratio	Gen 0	Gen 1	Gen 2	Allocated
UseSocketsHttpHandler	48.710 ms	0.4979 ms	0.4414 ms	48.694 ms	1.00	-	-	-	243.08 KB
UseHttpClientHandler	47.781 ms	0.5331 ms	0.4451 ms	47.884 ms	0.98	-	-	-	242.25 KB
UseCacheHttpHandler	1.252 ms	0.0665 ms	0.1907 ms	1.199 ms	0.03	-	-	-	247.48 KB

Test was done on an above-average high-speed internet connection. Effect would of course be A LOT bigger on slower networks.

However building a proper caching mechanism that deals with shared vs private cache, cache expiration, pruning (when it grows too large), lock contention for parallel requests, re-using the shared OS browser cache (like what wininet offers), etc is no trivial task. And even so, not having this at a platform level means there's no way to make caching possible with 3rd party libraries, because it currently has to be done manually at a very low level of the request.

/CC @karelz

[karelz]

@dotMorten given that we do not have any tight integration with wininet in SocketsHttpHandler, there is no benefit to have it in the platform. 3rd party library will have same chance to implement it as us.
Given that there is ton of policy around caching (e.g. store it on file system, or in memory, how much?), we do not think it should be part of SocketsHttpHandler inbox.

As such, I recommend to close the issue as Won't Fix. What do you think?

[dotMorten]

You know what I would think :-) Caching is an integral part of client apps - it needs an OOB option. We have it in .NET Framework, and we have it in UWP for good reasons. We don't however have it anywhere in .NET Core.

First of all, I don't think it's fair putting this on anyone to build themselves. I've only just completed building something that is only just good enough for my specific use-case, and it was a significant amount of work.

3rd party library will have same chance to implement it as us.

I don't see how? There are no common extensibility points that a 3rd party library can use that would turn it on for all dependencies. You'd have to build your own handler (or delegate handler around the sockets handler).

Given that there is ton of policy around caching

I've been through the RFCs around this a lot lately, and there's not a ton. It's actually a quite short list. See https://tools.ietf.org/html/rfc7234#section-3

 A cache MUST NOT store a response to any request, unless:

   o  The request method is understood by the cache and defined as being
      cacheable, and

   o  the response status code is understood by the cache, and

   o  the "no-store" cache directive (see Section 5.2) does not appear
      in request or response header fields, and

   o  the "private" response directive (see Section 5.2.2.6) does not
      appear in the response, if the cache is shared, and

   o  the Authorization header field (see Section 4.2 of [RFC7235]) does
      not appear in the request, if the cache is shared, unless the
      response explicitly allows it (see Section 3.2), and

   o  the response either:

      *  contains an Expires header field (see Section 5.3), or

      *  contains a max-age response directive (see Section 5.2.2.8), or

      *  contains a s-maxage response directive (see Section 5.2.2.9)
         and the cache is shared, or

      *  contains a Cache Control Extension (see Section 5.2.3) that
         allows it to be cached, or

      *  has a status code that is defined as cacheable by default (see
         Section 4.2.2), or

Or to put it more simple: It basically says to only cache GET/HEAD and only if there's no Authorization* header, it doesn't specify NoStore or Private*, there's an etag or expiration and you get a 200 OK.

Second, it should of course be opt-in, and not on by default (just like it is on netfx).

• You could store Auth and Private, but the simplest / safest solution is just to no do that, which is also how NETFX behaves.

[thargol1]

Perhaps caching can be implemented as on opt in on HttpClientFactory?

Some like this in startup.cs

services.AddHttpClient().AddCacheHandler(options =>
{
     // what ever you guys come up with, but maybe someway to inject an IMemoryCache here
});

You can than use the cache handler when it's allowed to do, as specified by the cache-headers of the returning response, or leave it up to the programmer.

[karelz]

Triage: We believe this kind of opinionated policy (esp. potential wininet integration) does not belong into vanila HttpClient, but it makes sense to keep it in HttpClientFactory.