dotnet: outputcache max-age incorrect

a simple controller like below: public class DetailController : Controller { [OutputCache(Duration = 300, VaryByParam = "id")] public ActionResult Index(int id) { return View(); } }

and the view `@{ Layout = null; }

<!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width" /> <title>Index</title> </head> <body> <div> @DateTime.Now.ToString() </div> </body> </html>`

when i first request the url http://localhost:80/Detail/Index?id=3, the max-age in response headers is correct (max-age=300), then i refresh the page (ctrl + f5), the respones state is 304, but the max-age in response headers is incorrect (max-age=63613066544) , and this cause the url link click request read the response from the browser’s disk cache ( 200 ok from disk cache).

the issue only happen in .net framework 4.6.2, not happen in 4.6.1 or early version.

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 1
Comments: 30 (8 by maintainers)

Most upvoted comments

We discovered this at Stack Overflow as the root cause to many problems. This should absolutely be a hotfix to existing .NET 4.6.2 installs. For many .NET 4.7 will not be an option for some time, and this is a critical bug. I’m honestly shocked that this went unsolved for months, we would never had expected such a known issue to stay open for this long. So many people on 4.6.2 will not ever even realize this is the root cause of some of their issues. We didn’t until it was too late. The cache poisoning downstream has already caused severe harm.

As a result of this bug, we have tens of millions of downstream requests that are cached in proxies we don’t control for over 2000 years. Only manual purges or volatile cache competition will purge them, which results in impossible to debug or remotely solve scenarios as our users report stale content. This is a huge, HUGE bug. It needs a fix for all ASAP. Though we’re willing to deploy .NET 4.7 on a whim, very few people are in that position. They need a hotfix, ASAP.

To work around this at all we have effectively disabled all OutputCache directives by stripping cache control at our proxy layer (Fastly) and removed it from anything not behind Fastly. This costs us in bandwidth, latency, and overall slower loads from uncached local resources for users. No workaround is desirable since this bug is so deep in the framework where you cannot safely solve it through user code. This is costing us dollars and performance every minute we have the workaround active.

+10

NickCraver on Apr 7, 2017

Just to provide an update on this: a fix is being tested and it is bound to be released with the 4.6.3 update or earlier.

albigi on Nov 7, 2016

This is critical! A bugfix should be released even before .Net 4.6.3

agrinei on Jan 20, 2017

Fixed: https://blogs.msdn.microsoft.com/dotnet/2017/05/17/net-framework-may-2017-preview-of-quality-rollup/

richlander on May 18, 2017

Few things are so out of your control as a cache you cannot purge as a developer. Maybe it would be time for MS to put some effort into writing serious unit tests that detect a problem like this before anything is released?

mortb on Apr 27, 2017