4

I'm trying out MVC 4 Beta's bundling and minification thru System.Web.Optimization. I was hoping that the site I'm using it for would receive a 304 (Not Modified) when I hit refresh.

I thought the point of the src to my js bundle, /desktop-js-bundle?v=D33JhbMl9LHkXSPBj1tfRkRI0lHeYVmbSMQqD59bXHg1 (with that version #), was that the version # changed only when one of the files in the bundle on the server was modified. Yet, every time I hit refresh and monitor the Network tab in Chrome's F12, it makes a request with that same version number and gets a 200 status.

Why doesn't it just return 304?, which would decrease the load and increase perf a decent amount. Thanks!

Hao Kung
  • 28,040
  • 6
  • 84
  • 93
Ian Davis
  • 19,091
  • 30
  • 85
  • 133

2 Answers2

2

Why doesn't it just return 304?

Because when you hit F5 you expire the cache of your browser. Basically your test is flawed. You should put links to this bundle in different pages (using the <script> tag). Then you should navigate to those pages using hyperlinks. Now observe the Network tab.

Also make sure you are running in Release mode.

UPDATE:

OK, after digging a little more here's what I found out. The 200 HTTP status code is indeed always sent which is normal. But the second time the bundle is fetched from the cache.

Here's the first request:

enter image description here

We can see that in this case the bundle comes from the server with HTTP cache response headers.

And here's the second request:

enter image description here

We can clearly see in this second screenshot that the bundle is served from the cache. Notice how the entire line is grayed. The HTTP 200 status code is fictional => the client doesn't even send an HTTP request to the server as it retrieves the bundle directly from its cache.

And I can observe the same thing in Google Chrome.

For the first request:

enter image description here

And for the second request:

enter image description here

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • but it's returning a 304 when it makes a request for a js file that I have outside the bundle. and a 304 for all the images. – Ian Davis Mar 21 '12 at 12:46
  • @IanDavis, are you running in Release mode? IIRC bundles are cached only in Release mode. – Darin Dimitrov Mar 21 '12 at 12:48
  • how can I tell? this is after I do the one-click publish I've set up in Visual Studio, then, I visit the site in production and hit refresh to see the `200`'s (not `304`'s). – Ian Davis Mar 21 '12 at 12:49
  • Do you have `` in your web.config? Normally if you have published your site in Release mode that should be the case. Also try what I suggested you: using links to navigate between pages that contain the same bundle script inclusion to see if you still get 200s. – Darin Dimitrov Mar 21 '12 at 12:50
  • I have `` in my published web.config. I wonder why visual studio does that. and, I did try the navigating among pages that have the same script ref - still 200's. let me try the web.config update. in meantime, does anyone know why Visual Studio does that? did I miss a setting? – Ian Davis Mar 21 '12 at 12:59
  • after changing it to ``, still 200's both when I hit Refresh and when I navigate between pages. Note: I do have one script ref going directly to a js file, and, that's returning 304's. Only my css and js bundles keep returning 200's, even when they keep using the same version #. – Ian Davis Mar 21 '12 at 13:02
  • Hmm that's very weird. Let me see if I can reproduce the issue. – Darin Dimitrov Mar 21 '12 at 13:04
  • @IanDavis, OK, I have updated my answer with the investigations I did. The conclusion is that the bundle is served correctly from the cache the second time. The 200 status code that you are seeing doesn't even come from the server. It's purely fictional. The client doesn't even send a request to the server as it directly fetches it from its cache. – Darin Dimitrov Mar 21 '12 at 13:21
  • @DarinDimitrov I am able to verify this is true for FF and Chrome, but have you checked IE? I'm running IE10 on Windows 8 consumer preview, and the JS is most definitely **not** being served out of browser cache, even on a link. It looks like until System.Web.Optimization supports ETags IE will be going back to the server for the request. – Emil Lerch May 09 '12 at 21:03
1

I had the same issue and the problem was with Microsoft.AspNet.Web.Optimization package. As described here: http://aspnetoptimization.codeplex.com/workitem/127, versions 1.1.2 - 1.1.3 are affected. After downgrade to 1.1.1 it works fine and 304 is returned for non-changed resources after refresh.

You can do it in Package Manager Console with following commands:

PM> Uninstall-Package "Microsoft.AspNet.Web.Optimization"
PM> Install-Package "Microsoft.AspNet.Web.Optimization" -Version 1.1.1
Tomasz Rozmus
  • 1,646
  • 13
  • 21