Forcing an update of a cached JavaScript file in IIS

May 12, 2006 Comment on this post [12] Posted in ASP.NET | DasBlog | Javascript

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

About Newsletter

Hosting By

Comment on this post [12]

Share on or or use the Permalink

May 13, 2006 12:08

Have you looked at Fiddler? (http://www.fiddlertool.com) It's an amazing tool for playing with HTTP.

Lee

May 13, 2006 13:30

But this doesn't take into account the many oddities of proxy servers around the world. I've worked on some big web properties (eg search engines) and the only way to reliably have Javascript changes propogated down to the client is to rename the javascript, or pass a new querystring to the javascript. Most people nowadays do this with a version number.

RichB

May 14, 2006 8:04

Yes, Rich, I hear you. I also have worked on a number of large public sites, and another issue to consider is SSL (where the large proxies don't get to see the headers.

Personally I like to version javascript with a versioned path.

Scott Hanselman

May 14, 2006 10:04

If OutputCache is purely server-side, then what is OutputCacheLocation all about?
http://msdn2.microsoft.com/en-us/library/system.web.ui.outputcachelocation.aspx

Not trying to a wise guy - honestly asking. I was under the impression (though never investigated), that ASP.NET DOES handle sending appropriate headers to the client and handling the request headers appropriately.

Joshua Flanagan

May 14, 2006 21:45

Scott, the behavior you see may depend on browser settings. Often, hitting F5 will force a refresh of the files -- meaning the client will disregard the expiration date and ask the web server if the file has been modified. That's why your example works. Your best approach is to not test using F5, and perhaps test using site navigation. (In IE this setting can be controlled somewhat, but using the defailt settings, you'll see that clicking a link to load a page acts differently than hitting F5.)

Generally speaking, "static" types known to IIS like GIFs and JS files will send 304 not modified responses to these files, assuming of course that clients send the if-modified-since information. However, the _most_ important point is this:

If you set the content expiration to, say, 7 days, the browser may not request the file at all for those 7 days. That's why touching the file may do no good -- if you've modified it, the browser will never get the file until it expires. This is by design, to cut down on the number of request/responses sent to and from the server. 304s are not as lightweight as people assume -- the connection and overhead still slows page load time, and sometimes, if files are small (<4K) it's just as performant to resend the file. With JS files, though, this kind of sync-problem happens all the time, and as suggested here already, the best approach is to version the files in the filename. If you're expiring content after some timeframe, touching the files will likely not work... I blogged about this awhile ago:

http://www.structuretoobig.com/home/show.aspx?bid=173

-Brian

Brian

May 14, 2006 21:58

Josh - Yes and no. I'll write something up to explain. You CAN control them to some extent, but you will have to call SetEtag, Expires, and SetLastModified yourself.

Brian - F5 will not force a refresh of an HTTP GET if the files exist in local cache on any browser that I know of. Now, *CTRL-F5* will supress the browser's If-Modified-Since headers and effectively "blow through" the cache.

You say, the browser may not request the file for 7 days. Per the spect the browser must always request the file (unless you're using FasterFox or some http-spec breaking client side tool. It always does request the file in my experience (while sniffing HTTP.) Do you have evidence that points to the browser not requesting at all? (like an HTTP trace I could repro?)

Yes, 304s aren't very lightweight, especially if you have an AuthenticationTicket or some cookies, they can be as much as 1-2K.

Scott Hanselman

May 15, 2006 0:15

Hi Scott--

Sure, I can probably demo this behavior using Fiddler. When I set the expiration of files to some date, say, 7 days, the browser (IE 6 in my test case) will NOT request the file again for that time.

Whether or not IE will refresh, or whether or not F5 has an effect depends on the cache settings of the browser. I just double-checked, and it's working as I've described ... let me set up a test page and we can both test it out...

-Brian

Brian

May 15, 2006 0:56

OK ... Here are two test pages to use. Note, this page will only be up for a day or two. I also recommend using Fiddler, and note that this behavior depends on how you've set your browsers cache functionality.

First, here's a page that does NOT use content expiration for anything:

http://clanmda-seattle.dyndns.org/test_noexpire.aspx

On most default installations, either hitting F5 or clicking the link that just navigates to the page again will result in the one aspx page being requested, and then 10 image requests (should be 304). Note: no content expiration is set for anything, but we're still getting 304's (as expected).

Now on to this page:

http://clanmda-seattle.dyndns.org/test_expire.aspx

When you first load the page, you should get the 11 200's for the aspx and the image files. All images have a 7 day expire window. I can see this in Fiddler with the max age field.

If you click the link to go to the page again, both IE 6 and IE 7 (on my installations) will ONLY request the aspx page -- no images are requested. If I hit F5 (NOT ctrl-f5) I'll get the single 200 for the aspx page, then 10 304's for the images. You see, the images are NOT being requested unless I instruct the browser to refresh.

Becaues these images are only 1K in size, the 304 is almost as bad because the image can be resent with nearly the same efficiency as sending the 304.

I actually did (back when I blogged that entry) a few long distance tests with some machines in NY connecting to my machines in Seattle to test responsiveness. A buddy of mine performed the test, and I confirmed the images were not even requested after the original GET. Pages that have a huge number of images get some huge perf benefit by not requesting the file.

Now, most people can tinker with their default behavior of browsers to control the cacheability. The safest assumption is: when setting content expiration, do not assume that touching the file will be suffient -- in most cases, it won't be. That's where the ol' filename-based versioning is so useful :)

Let me know how your test goes...

-Brian

Brian

May 15, 2006 3:43

Interesting stuff, Brian. That's a surprising result, but it makes sense. I assume it works the same way with Javascript? (It's not a specific result for graphics?)

One think I would point out though, that the second result only seems to hold during a single browser session. When I shut IE6 down and visited again, the browser issued 304s.

That indicates to me that if the user shuts down the browser and returns later, the "touch" will work because of the 304s. If the files change WHILE the 'session' is up, then you're right.

Scott Hanselman

May 15, 2006 6:05

Scott --

That's interesting ... I tried closing my browser (I actually had a reboot, too) and tried connecting to my expire test page... and got the same result (only the 1 request, no images). Even if I set IE6 to check for new versions on each request, it still didn't request it unless I hit F5. There's obviously a setting somewhere you and I have different :)

I'm not sure if the same behavior is true for Javascript, it may not be. But if there's anything I learned, I never rely on the client. Even between the two of us there's some differences in behavior that could be disasterous (relatively speaking, of course) if clients were so unpredictable. It would be nice to have a very clear standard for cacheability, wouldn't it?

But, overall, I do agree with the browser not re-requesting the file. On some controls that have a zillion <1K GIFs that never change, I've seen it be a real bottleneck.

Have you used Fiddler with Firefox? I haven't done that yet (not sure how easy it is to configure)...

Brian

May 15, 2006 13:03

One quick hack that you might find useful for forcing file reloads without having to delve into IIS settings is to tag a unique querystring onto the end of the URL.

Referring to "myScript.js" in a line of code becomes "myScript.js?preventCache<%=Now%>".

This works by adding timestamp into the path, IIS will treat this request as a unique file and force-load a new version to the browser - works just as well for graphics. This is an example from an ASP page, I'm sure there is an alternative technique for any server-side scripting language. I'll usually use this technique during development to prevent my browser from displaying old versions of files I've been workign on, then stripping out all the preventCache code when the site goes live.

topofthepods

May 19, 2006 18:12

That is the reason why I have done this with Ajax.NET, too. It is creating the http headers to enable client side caching.

Michael Schwarz

Comments are closed.