OutputCache has no effect

Question

I'm back on a MVC app where I thought that output caching was working as expected. However, while revisiting it, I see that the OutputCache attribute I use has no effect (Duration is set to a high value). Whether I add it or not, the breakpoint in my action is always hit and Firebug shows me a 200 OK on the requested page in each case.

In a more complex action where I use VaryByCustom, the GetVaryByCustomString method in global.asax is never called. I know that it was called in the past since I was able to debug there but now it's not.

I wonder what I did to break this... Any idea?

(in order to not only test localhost, I use a dyndns.org address so that it's a valid external URL. I also use IIS).

Update: when I use the localhost URL, targetting the same url does not enter the action code again. Hitting F5 does. When using the internet URL it always visits the action code.

Update 2: Fiddler is showing this in the response headers:

200 OK

Cache:
Cache-Control: public, no-cache="Set-Cookie", max-age=86400
Date: Mon, 16 Jul 2012 19:38:46 GMT
Expires: Tue, 17 Jul 2012 19:38:46 GMT
Vary: *

Expires = Date + 24h each time I request the same url, which shows that a new page is served each time. Also I should get 200 the first time and 304 thereafter.

Answer 1

Just discovered the culprit, which is contextual to my application:

If I remove the 51degrees.mobi nuget package from my app, it just works again. Put it back (even without using its features) and caching is dead. Well, in fact there are 2 cases:

• If you just add the package, GetVaryByCustomString is never called. The action method is called once correctly and then is served from the cache.
• If you add the package AND you also use a CompressFilter attribute, then GetVaryByCustomString is never called AND the action method is always called (no page served from the cache).

I posted to their forums to report this issue.

Update: these issues appear starting with 51degrees version 2.1.4.9. I notice that this is the first version using Microsoft.Web.Infrastructure, in case this is relevant...

Update 2: they found the cause of this issue and it will be fixed.