Add support for versioning resources [SPR-7141]

[spring-projects-issues]

Keith Donald opened SPR-7141 and commented

As a user, I would like support for resource versioning so it is possible to get the benefits of caching with the ability to refresh changes.

Implementation option #1

---

Automatic versioning with file timestamps e.g. /resources/main.123456789.css

Implementation option #2

---

Manual versioning with version number e.g. /resources/version-1.0.0/main.css

Both options would require ResourceHttpRequestHandler to strip out the version number from the request URI to obtain the "real" resource path. In addition, a view helper function or tag would be needed to generate versioned URLs e.g. <spring:resource name="main.css"/> might generate http://localhost:8080/app/resources/main.123456789.css.

Resources:
http://stackoverflow.com/questions/118884/what-is-an-elegant-way-to-force-browsers-to-reload-cached-css-js-files
http://particletree.com/notebook/automatically-version-your-css-and-javascript-files/

---

Affects: 3.0.2

This issue is a sub-task of #12058

Issue Links:

• Support for generating links to static resources such as CSS and JS files hosted at a CDN such as Amazon Cloudfront [SPR-7745] #12401 Support for generating links to static resources such as CSS and JS files hosted at a CDN such as Amazon Cloudfront

2 votes, 4 watchers

[spring-projects-issues]

Keith Donald commented

Ideas:

Tag based:

<spring:resource value="foo.css"/> generating /resources/${version}/foo.css

<spring:resource value="foo,bar,baz.css"/> generating /resources/${version}/foo,bar,baz.css

or EL function based:

${resource("foo.css")}
$(resource("foo,bar,baz.css")}

• Need a pluggable ${version} resolver mechanism (timestamp-based strategy, property based strategy)

• Version number should be optional; don't cache if version number not provided e.g. /resources/foo.css

[spring-projects-issues]

Keith Donald commented

Another benefit of using a tag like spring:resource is it would encapsulate the host of the resources. In a dev environment this might be the developer's local workstation. In a production environment this might be a CDN or dedicated resource host (see how Stackoverflow.com is setup). It should be able to switch the host of the resources without changing the pages.

[spring-projects-issues]

Robin Sander commented

@Brian: did you close this as a duplicate of #12401 or which one? In case of #12401, I think there's a difference between those two: #7745 is about serving variants of a ressource while this one is about generating different URLs for the same resource with the benefit of a maximum caching time on client side. So they both require some means for URL generation but this one requires a special resolver, too.
I don't know if Spring should support either of one because in the end this would require some kind of preprocessing to make it perfect e.g., to cache images referenced from CSS. And there are already some solutions out there (jawr, wro4j, ...) but all of them require a special runtime setup or there's no Gradle integration for the preprocessing. So it would be terrific to have a Gradle task for generating checksums and URL rewriting + a taglib for access + a Spring resolver for all this but then it might be easier to improve the Spring and Gradle integration of Jawr!

[spring-projects-issues]

Brian Clozel commented

Hello Robin Sander, this is closed as a duplicate of #15561 (and its subtasks).
There is already something in master for this case (and a much broader, extensible, mechanism for resolving/generating URLs for resources).

Please comment on #15561 if you've got feedback on that implementation.
Thanks!

[spring-projects-issues]

Robin Sander commented

Thanks Brian, sounds promising!