Does asset cache key need a dependency on Accept-Encoding header?

[pdragicevich]

It can cause cache invalidation if requesting an asset from different browsers sending different Accept-Encoding headers.

I can't see it used anywhere apart from Asset.GenerateCacheKey method.

[jzabroski]

Can you give an example of two different browsers so I can reproduce this issue?

Is the cache invalidation due to # of cached keys in the cache causing older keys to get flushed out, or is it simply upon request, it removes the previous value from the cache, potentially leading to cache ping-pong?

Top-down, the way this should work is that encoding should be virtualized, and split out into multiple caches - this is essentially what the .NET 9 MapStaticAssets stuff does by pre-generating the br encoding, etc in the $"{environment.ApplicationName}.staticwebassets.endpoints.json" file - it decouples the asset from the "endpoint" (an "endpoint" in MapStaticAssets includes the encoding).

[pdragicevich]

I was writing a startup task for our ASP.Net core app to warm up the bundles. So the two browsers are HttpClient vs what I was using to test (Brave but could be anything). HttpClient wasn't sending any header but the browser was.

AssetResponseStore.cs deletes any "old" cached files so it causes cache ping-pong.

// First delete old cached files
IEnumerable<string> oldCachedFiles = Directory.EnumerateFiles(_options.CacheDirectory, name + "__*.cache");

I ended up writing our own implementation of IAsset and IAssetPipeline to work around this for now but that's not the best situation to be in.

(Also some optimisation for loading bundle files but I think there's already an issue logged for that.)

I couldn't really merge in what I wrote as it's specific to our use case. Not sure about the high level but removing the Accept-Encoding if statement fixed things for what we're doing.

[jzabroski]

It seems weird to cache the encoding string vs. the final negotiated encoding. I guess if you're using IIS to host, it could be doing its own response compression.

It would seem more logical to support a standard set of encodings. I think this is why .NET 9 MapStaticAssets enumerates the "endpoints" (encodings). That prevents a denial of service attack on the cache.

The behavior may need to be slightly configurable or else people will need to change where in the pipeline they include UseWebOptimizer()