Cache-Control: no-cache breaks the middleware

[colltoaction]

TL;DR: this breaks with the Cache-Control: no-cache header since the IResponseCachingFeature feature is not set up and we hit this exception.

---

Hi,

I'm just starting with your middleware, and the basic functionality is great. I just specify a [ResponseCache] and it gets cached automatically, which is awesome :).

But I'm getting an error 500 each time I do "Ctrl+F5" or I disable caching in the Chrome dev tools. The error is the one in the title:

An unhandled exception occurred while processing the request. InvalidOperationException: 'VaryByQueryKeys' requires the response cache middleware.

Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilter.OnActionExecuting(ActionExecutingContext context)

The error is the same as if I had not called app.UseResponseCaching(); or called it in the wrong order. The exact line is the following, which shows that it's checking for a Feature of type IResponseCachingFeature: https://github.com/aspnet/Mvc/blob/d8c6c4ab34e1368c1b071a01fcdcb9e8cc12e110/src/Microsoft.AspNetCore.Mvc.Core/Internal/ResponseCacheFilter.cs#L132.

I investigated the source code and came to the conclusion that the error is produced because:

1. Browsers send Cache-Control: no-cache header
2. The request is marked as not cacheable here
3. Since it's not cacheable we skip the call to ShimResponseStream
4. And we don't set up the Feature for the next middlewares.
5. So we end up with the mentioned exception in this line

If you could give me any workaround until a fix is published I'd really appreciate it!

Thanks,
Martín.

[Tratcher]

@tinchou Thanks for the detailed investigation. We'll get this dealt with ASAP. One possible workaround would be to always set an IResponseCachingFeature. Try putting this between the caching middleware and MVC:

app.Use((context, next) =>
{
  if (context.Features.Get<IResponseCachingFeature>() == null)
  {
    context.Features.Set<IResponseCachingFeature>(new FakeResponseCachingFeature());
  }
  return next();
});

@muratg @DamianEdwards This is a patch candidate bug.

[colltoaction]

Can confirm the workaround works for me.

I implemented FakeResponseCachingFeature as:

    public class FakeResponseCachingFeature : IResponseCachingFeature
    {
        public string[] VaryByQueryKeys
        {
            get => null;
            set { }
        }
}

[JunTaoLuo]

@pranavkm we'll need to build a 1.1.1 branch for this.

[JunTaoLuo]

@Tratcher and I think the middleware needs to be fixed. The feature should be added regardless of whether the request is cacheable since it is used when generating the response. Cache-Control headers are unidirectional and response generated by a request with no-cache can be used to update the existing entry in the cache.

[Tratcher]

In other words, the request header Cache-Control: no-cache says do not retrieve the resource from cache, it does not prohibit caching the new response.

[colltoaction]

Should clients be telling the server when not to use the cache? Before using this middleware my implementation was based on IMemoryCache, and I never thought about checking the headers because it was an implementation detail of the server. I've looked around but haven't found specific information.

[DamianEdwards]

@tinchou when it comes to HTTP-based response caching, yes, the client still maintains ability to send cache control headers, thus affecting upstream caching behavior. As a result, you shouldn't rely on whole response caching to control load on your application. Using IMemoryCache or the <cache> Tag Helper are ways you can cache parts of the your application logic and fragments of HTML responses separately from systems that use HTTP cache control headers.

The old docs for ASP.NET Caching (from the System.Web days) covers the differences quite nicely in this introduction.

All that said, it might still be nice to have the response caching middleware support a mode whereby it ignores all client-based HTTP cache control headers, and instead acts as a completely server-controlled cache.

[colltoaction]

@DamianEdwards yes, I think that would be my preferred scenario. Since I'm already encoding caching information in my ResponseCache attribute, it'd be really nice if I could have server-side caching automatically set up too.

But if the client can void my cache as they please, then that defeats the whole performance story.

---

EDIT:

I'm curious, why would anyone want the server to ignore the cache when told by the client?

[DamianEdwards]

Because that's normally how HTTP-based caching works. There's a client, server, and any amount of intermediaries in between, and they all speak HTTP and participate in caching, using the same cache control headers.

We should investigate the caching behavior of the popular edge caching appliances & services, along with other frameworks, to see how they differentiate these concerns.