Runtime: HttpClient WebRequestHandler.CachePolicy Replacement

[danielcrabtree]

I've run the Portability Analyzer and found that HttpClient does not implement WebRequestHandler.CachePolicy and I don't seem to be able to find any replacement for this. @karelz suggested asking here.

A similar question was asked on Stack Overflow and has no answer.

I would like to know if there is any equivalent to WebRequestHandler.CachePolicy in .NET Core for use with HttpClient.

If there is no equivalent, I would like to know what the effective equivalent default value is in .NET Core?
More specifically, .NET Core's implementation is equivalent to a RequestCacheLevel of BypassCache OR CacheOnly OR CacheIfAvailable OR Revalidate OR Reload OR NoCacheNoStore?

Furthermore, is it consistent across platforms?

From examining the source, I think it might be BypassCache, but I'm not sure and would like confirmation. I'm also unsure if an OS level cache is used on Windows or elsewhere or whether .NET Core bypasses those.

If BypassCache is not the current equivalent default on .NET Core or if any intermediate caches such as OS caches are being used on any platform, I think there needs to be the option to set BypassCache, so we're able to implement our own caching on top of HttpClient.

[karelz]

@davidsh @CIPop @stephentoub @Priya91 do you have any advice?

[davidsh]

BypassCache is the behavior on .NET Core.

[danielcrabtree]

Thanks @davidsh.

[dotMorten]

Since .NET Core 3.x is now starting to be heavily used with client apps, having access to OOB client cache becomes quite important for responsiveness. Should this be reopened as a feature request to add an OOB implementation? (preferably built around the system-wide ones that are already there, like the IE cache etc). It's quite a lot to ask users to understand and implement cache-control, etag, expiration, cache size limits etc etc. In our case asking our users to move to .NET Core would effectively mean a drop in performance.