3

I'm using Microsoft ASP.NET Web Optimization Framework

As you may know, it can concatenate all JS/CSS into single file. You can define output file name in config and to ensure that user browser will pickup updates JS/CSS it adds parameter like v=yUVjELgc9foFnhZgsvMfx2DhVRLKWK-w69IoCVhJ_aM1

Link looks like:

src="/scripts/js/jquery?v=yUVjELgc9foFnhZgsvMfx2DhVRLKWK-w69IoCVhJ_aM1"

I heard that not all browsers supports that parameter and not refreshing cache.

Can I be sure, that all browsers will update cache using this approach or I have to manually generate new file name? Is there any table, where I can see browsers, that doesn't support that?

Thank you

Robert Koritnik
  • 103,639
  • 52
  • 277
  • 404
Sergejs
  • 2,540
  • 6
  • 32
  • 51
  • It's not on browsers to support particular query variables. They just look at request URL whether they've already cached it or not and what headers it head when received the last time... So as long as that value will change, browsers will request a new version. – Robert Koritnik Jan 25 '13 at 12:59
  • All browsers? How do I prove it to my team lead, who's saying, that it doesn't work for all browsers? – Sergejs Jan 25 '13 at 13:01
  • Make a change in the code and hit refresh. If the change takes effect then it works. Perhaps an alert('1'); and then alert('2') – Aram Kocharyan Jan 25 '13 at 13:02
  • @Sergejs: Ask your team lead to prove he's right. Because he'll have a much harder job finding some obscure browser that doesn't support than than you. If you have a set of *supported browsers* for your app, you can test against those and provide results whether they support reloading when you change that particular variable... Maybe your team lead (doesn't know shit) and was relating to # segment in the URL and not query variables. # segments normally don't reload anything. That's true. But they're a completely different beast. – Robert Koritnik Jan 25 '13 at 13:08
  • @Robert Koritnik: you're right, thank you – Sergejs Jan 25 '13 at 13:29
  • 1
    @Sergejs: I know what you meant... That I'm right about your team lead not knowing s****. ;) – Robert Koritnik Jan 25 '13 at 13:45

2 Answers2

6

I heard that not all browsers supports that parameter and not refreshing cache.

Browsers don't need to "support" it.

It's purpose is to change the URL to the script.

Since the URL is different, the resource at that URL won't have been cached.

For the technique to fail to work the browser would have to have a severe bug (in which it special cased query strings for cache handling). This would break vast amounts of the web as (for example) searching google for "kittens" and then searching for "puppies" would show the cached kitten results for the puppy search.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
0

This will work across browsers because when you send a different URL altogether, which hasn't been seen before, the browser shouldn't use a cached response, as it can't verify it is correct.

RFC-2616

13.1.1 Cache Correctness

A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request

If you are still worried and want to stick to something more clearly defined in the standard, you could also set the Last-Modified header for those files, when sending them out.

Browsers send out a request containing If-Modified-Since and when they request an older version, the server won't return a 304 Not Modified, and will return a fresh copy, preventing the cached file being used.

Anirudh Ramanathan
  • 46,179
  • 22
  • 132
  • 191
  • 1
    This is a fairly inefficient way to do caching, as a request response still has to be made and a response waited for (rather then the browser being able to go "This is still good for the next two weeks, I'll won't bother the server at all"). – Quentin Jan 25 '13 at 13:06
  • 1
    Agreed. I was just suggesting an alternative. – Anirudh Ramanathan Jan 25 '13 at 13:08