4

There is a question about getting the path to Static Resources dynamically in apex and it has some good answers. Here it is for reference.

Dynamically get the path to a static resource

However, I've noticed that at some point, (I'm not sure when). Using the static resource url without the timestamp in it has started working fine.

/resource/MyNamespace__MyStaticResourceName

works just as well as

/resource/1400779442/MyNamespace__MyStaticResourceName

I haven't been able to find anything about this in the documentation or release notes. So my question is...

Is using the first method without the timestamp dangerous and unsupported? Can anyone think of drawbacks? Is caching behavior changed?

Improve this question

3 Answers 3

Reset to default
4

The timestamp is essentially a version. Each new upload revs the timestamp. Without it, browsers cache the resource and each subsequent page load will pull from cache. Even if you upload a new version, any user who has already hit your page will have the cached version and the only way for them to get the new version is to dump their cache.

Improve this answer
3

This behavior is not new.

Building the URL without the timestamp is not dangerous but it's also not the recommended approach to referencing a static resource.

The number in the URL is the number of milliseconds elapsed since Jan 1, 1970 and it is a cache-buster to provide uniqueness and ensure that the resource isn't pulled from the browser's cache and will instead be retrieved fresh from Salesforce.

If you're building one of these resource URLs manually in apex, you could use the DateTime.getTime() method to get the current number of ms and add that value into your URL.

Improve this answer
2
  • Thanks, that's what I thought, but it's good to have some verification on this. I accepted the answer by @greenstork because he posted first, but I appreciate the answer.
    – plusplusben
    Commented May 22, 2014 at 17:56
  • One downside to using DateTime.getTime() to insert your own timestamp is that you force the browser to re-download the resource everytime your page loads, whether or not it has changed, thus defeating the purpose of caching. You'll increase the amount of bandwidth you use and the load time of the page.
    – JDB
    Commented Jan 15, 2016 at 20:06
3

To further emphasise Mark's last comment, this code makes use of JavaScript's Date.now() for the same purpose - very useful for JavaScript apps that need to access many static resources. So a timestamp is needed, it just doesn't have to be the exact timestamp of the static resource.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .