Cache-Control="no-cache" always in "Microsoft.AspNet.Web.Optimization" -Version 1.1.2


Hi all,

After upgrading to 1.1.2 the response header Cache-Control always is "no-cache" and Pragma also is "no-cache". When I uninstalled and installed back Microsoft.AspNet.Web.Optimization 1.1.1. It started to work as before the Cache-Control become public.

I'm 100% sure that this is bug in 1.1.2 as I did only these 2 commands in console and it started to work
Uninstall-Package "Microsoft.AspNet.Web.Optimization"
Install-Package "Microsoft.AspNet.Web.Optimization" -Version 1.1.1

file attachments


IDisposable wrote Mar 20, 2014 at 6:49 PM

I'll bet you are using Google Chrome and have Developer Tools open and under Settings/General you have the Disable cache (while DevTools is open) checked. Don't ask how I know....

Eltrab wrote Apr 9, 2014 at 3:23 AM

We experienced this issue too. The problem occurred with 1.1.2 and 1.1.3, but reverting to 1.1.1 resolved our problem.

We reference the bundles from a different website, so we are unable to use the inbuilt mechanism for changing the querystring when files are updated. We use our own mechanism, e.g. appending ?v=1234 to our querystring and incrementing that number on each update.

When we go to the bundle with any quertystring attached, e.g. 'bundle.css?v=1234' the server responds with a no-cache header. This will persist on reloads and with any querystring value. However if we access the URL with no querystring then the correct 'public' cache header is returned.

This is where it gets weird - once we've accessed the URL without a querystring, then the URL starts working with querystrings appended. This persists, presumably until the AppDomain reloads.

i.e. if I visit these URLs in the following order then the behaviour is -
  1. bundle.css?v=1234 : no-cache
  2. bundle.css : public
  3. bundle.css?v=1234 : public
Our workaround for the time-being is to use 1.1.1.

snokleby wrote Apr 9, 2014 at 9:13 AM

We see the same thing. Changing the cache-bust-querystring changes the cache-headers.

I made two bundles with identical content, and one gets no-cache, the other gets public. They also have different query-strings, even though the content is identical. This is stable in different browsers and requests.

If I request the bundle which originally had no-cache headers, with the query-parameter for the bundle which got correct cache headers, this bundle also got correct cache-headers.

justintubbs wrote Apr 24, 2014 at 2:14 PM

Having issues with anything above 1.1.1 as well. 200 OK instead of 304 Not Modified being returned for all calls to bundled JS or CSS.

suhasj wrote Apr 29, 2014 at 9:10 PM

@akub19, Eltrab: I ran my sample application with Optimization 1.1.1, 1.1.2, 1.1.3 and in call cases the cache header for the bundle is public. I have attached the screenshot

Few questions that might help me reproduce the error
  • Whether the application is in IIS or IIS Express ?
  • How is the bundle being added ? How many files and how the folder is structured

akub19 wrote Apr 30, 2014 at 1:16 AM

Whether the application is in IIS or IIS Express ?
The problem was noticed on production site in W2K8 R2 SP1 if I'm not mistaken. This is what I get in console:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

It is Azure VM based on some Microsoft image.

I don't remember if I was able to replicate the issue locally on Dev environment. But currently I'm running on 1.1.4. I didn't work for some time with the project and didn't have a chance to check it. I have checked right now and I confirm the problem persist in Chrome but it works in IE, i.e. I get 304.
I need to check it a bit more especially the things which IDisposable said.
Now it seems that it is a Chrome bug but if this is a Chrome bug why it was fixed when I rolled back to 1.1.1?

The bundles I can't describe in a few words as I use dotless compiler.
Please give me some time I'll check it in a few hours.

akub19 wrote Apr 30, 2014 at 4:58 AM

I'll bet you are using Google Chrome and have Developer Tools open and under Settings/General you have the Disable cache (while DevTools is open)
Yes, I was using Chrome dev tools, but I have unchecked that option and I still have no-cache in Response headers.

Remote Address:
Request URL:http://static.bp4u.com.au/Content/bcss?v=Ct3bDBBuFUUUDcsM0L96RNdhzSYbtv84S13k-sCiaUI11.css
Request Method:GET
Status Code:200 OK
Request Headersview source
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36
Query String Parametersview sourceview URL encoded
Response Headersview source
Content-Type:text/css; charset=utf-8
Date:Wed, 30 Apr 2014 01:21:07 GMT

The important thing is that I was wrong when I said that I have 1.1.4. I had right now 1.1.3.
So I took the version was deployed last time and reinstalled 1.1.1

PM> Uninstall-Package "Microsoft.AspNet.Web.Optimization"
Removing 'Microsoft.AspNet.Web.Optimization 1.1.3' from BP4U.WebSite.FE.
Successfully removed 'Microsoft.AspNet.Web.Optimization 1.1.3' from BP4U.WebSite.FE.

PM> Install-Package "Microsoft.AspNet.Web.Optimization" -Version 1.1.1
Attempting to resolve dependency 'Microsoft.Web.Infrastructure (≥ 1.0.0)'.
Attempting to resolve dependency 'WebGrease (≥ 1.5.2)'.
Attempting to resolve dependency 'Antlr (≥'.
Attempting to resolve dependency 'Newtonsoft.Json (≥ 5.0.4)'.
Installing 'Antlr'.
Successfully installed 'Antlr'.
Installing 'Newtonsoft.Json 5.0.4'.
Successfully installed 'Newtonsoft.Json 5.0.4'.
Installing 'WebGrease 1.5.2'.
You are downloading WebGrease from webgrease@microsoft.com, the license agreement to which is available at http://www.microsoft.com/web/webpi/eula/msn_webgrease_eula.htm. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.
Successfully installed 'WebGrease 1.5.2'.
Installing 'Microsoft.AspNet.Web.Optimization 1.1.1'.
You are downloading Microsoft.AspNet.Web.Optimization from Microsoft, the license agreement to which is available at http://www.microsoft.com/web/webpi/eula/aspnetcomponent_rtw_enu.htm. Check the package for additional dependencies, which may come with their own license agreement(s). Your use of the package and dependencies constitutes your acceptance of their license agreements. If you do not accept the license agreement(s), then delete the relevant components from your device.
Successfully installed 'Microsoft.AspNet.Web.Optimization 1.1.1'.
Adding 'Microsoft.AspNet.Web.Optimization 1.1.1' to BP4U.WebSite.FE.
Successfully added 'Microsoft.AspNet.Web.Optimization 1.1.1' to BP4U.WebSite.FE.

Here's the package list (not full as I removed all packages which I believe have no relation to that problem)

<package id="AjaxMin" version =" 5.7.5124.21499" targetFramework="net45" />
<package id="Antlr" version ="" targetFramework= "net45 " />
<package id="Microsoft.AspNet.Mvc" version= "5.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.Mvc.FixedDisplayModes" version= "5.0.0 " targetFramework="net45" />
<package id="Microsoft.AspNet.Razor" version= "3.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.Web.Optimization" version= "1.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi" version= "5.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version= "5.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version= "5.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.WebHost" version= "5.1.1 " targetFramework="net45" />
<package id="Microsoft.AspNet.WebPages" version= "3.1.1 " targetFramework="net45" />
<package id="Microsoft.Web.Infrastructure" version= " " targetFramework="net45" />
<package id="Newtonsoft.Json" version= "6.0.1 " targetFramework="net45" />
<package id="WebGrease" version= "1.6.0 " targetFramework="net45" />

I have 2 virtual machines behind load balancer. They have numbers 2 and 3.
The 2 box has after deployed I redeployed that version 1.1.30904.0
The box 3 has 1.1.3. I have created a simple html page which requests css directly without load balancer, url rewrite and so on.

Here it is

<!DOCTYPE html>
      <link href="http://bp4u.cloudapp.net:64372/Content/bcss?v=Ct3bDBBuFUUUDcsM0L96RNdhzSYbtv84S13k-sCiaUI11.css" rel="stylesheet" />
      <link href="http://bp4u.cloudapp.net:64373/Content/bcss?v=Ct3bDBBuFUUUDcsM0L96RNdhzSYbtv84S13k-sCiaUI11.css" rel="stylesheet" />

64372 - endpoint for the 2nd box,

64373 - endpoint for the 3rd box,

When I open in a chrome 2nd time for 64372 I have 304, but for 64373 always I get 200 with Pragma: no-cache

I'm 100% sure that this is a bug in Web.Optimisation as this problem also appears in IE. It has nothing to do with the Chrome.
Here you can find more details with the screenshots.

The last screentshot from IE, confirms that bug.

akub19 wrote Apr 30, 2014 at 5:03 AM

Please check with the simple html page I provided in the previous post. Modify it for your case to verify if in your case the bug will appear.

Please let me know if you need details about the bundles. But I don't think that it should affect it.

ludwigs3rd wrote Apr 30, 2014 at 2:42 PM

We had similar issues. Got no-cache with v1.1.2. Tried v1.1.3 to no avail. Reverted to v1.1.1 and things seem to come back with cache headers. We experimented with hitting javascript files using just regular script tags and jQuery using $.getScript using the cache option.

chrisdenning wrote Apr 30, 2014 at 9:06 PM

We hit this today, after upgrading from 1.1.0 to 1.1.3. It caused major issues because the no-cache header stops our CDN caching the file, and hugely increases the load on the origin server.

After finding this bug report, downgraded to 1.1.1 and it appears to have solved the problem for now.

I also checked another site I run and realised the no-cache header was showing there, and so affecting performance, but as it's a lightly-used site, hadn't noticed the impact.

runxc1 wrote Sep 4, 2014 at 3:09 PM

So this was reported in January, has this been fixed yet?

timw78 wrote Jan 7, 2015 at 1:39 PM

Still an issue using IE11 and 1.1.3

hellkama wrote Mar 3, 2015 at 11:40 PM

I am experiencing the same issue but only when I use Azure CDN to deliver the bundles.

Any fix incoming?

kevinsbennett wrote Jun 10, 2015 at 10:49 PM

Also running into this problem when I use Azure CDN with bundles.

christian_ulson wrote Oct 17, 2015 at 9:51 PM

I'm still await for de resolution

ramasua wrote Mar 24, 2016 at 4:06 PM

I am seeing the same behavior with v1.1.3 Seems like a bug. Is there any resolution other than going back to v1.1.1 ?

mjw22 wrote Jul 14, 2016 at 12:21 AM

Currently seeing the same behavior. Any progress?