Support Content-based Hash Fingerprinted URLs in ResourceHttpRequestHandler [SPR-10310]

[spring-projects-issues]

Kent Rancourt opened SPR-10310 and commented

ResourceHttpRequestHandler's configurable "cacheSeconds" property is a great performance feature that allows the setting of a far-future expiry date on the static resources it serves. Of course, the downside to this is that if static resources are modified in a subsequent release, browsers that already have them cached won't request new versions for a long time and therefore wind up utilizing stale resources.

To circumvent this, a "cache-busting" strategy is called for in order to "trick" browsers into making a new request by supplying them with a different URL to follow. The Spring reference documentation (chapter 17) offers up one possible strategy for accomplishing this, but with this being a common concern, should support not be built directly into Spring MVC?

I have been inspired by how the Ruby on Rails "asset pipeline" accomplishes cache-busting, so if I may be so bold as to suggest an implementation, something like the following might work nicely:

1. Provide a series of custom JSP tags like <resource:image/css/javascript>. If cache-busting is enabled, these tags will seek out the indicated resource (by looking in the same locations that ResourceHttpRequestHandler is configured to serve resources from). Upon finding the resource, it will calculate an MD5 checksum of that resource and incorporate that fingerprint into the URL that it outputs into the src or href attribute of whatever HTML element the tag is producing.

By way of example, <asset:image src="/images/logo.png"/> might produce <img src="/<context-root>/resources/images/logo-<md5sum>.png"/>

(Also, a simple Map can be used internally to cache calculated checksums to improve the performance of this algorithm on subsequent executions.)

2. Add a "useCacheBusting" property to ResourceHttpRequestHandler (and the <mvc:resources> tag in the Spring MVC config namespace). Enhance this class to detect and strip the MD5 checksum suffix from the URL before looking for the requested resource. (There is no need to even DO anything with the MD5 checksum. It was only there to trick the browser into make a new request.)

Developers using this enhancement would need to do no more than enable it using the namespace and use the <resource:image/css/javascript> JSP tags.

The strategy, apart from being quite seamless, is also wholly compatible with additional strategies that might be used to accelerate the serving of static resources. For instance, if a develop wishes to short-circuit requests for static resource by serving them from the web server, there are two options that are fully compatible with the cache-busting strategy outlined here:

1. Use a Maven build plugin to suffix static resource filenames with MD5 checksums. Whatever deploy process copies the static resources to the web server will then be copying resources with the exact names that the new JSP tags will be directing the browser to request.

2. If the developer has control of the web server and doesn't like Spring core JMS pom.xml #1, they can also consider using web server rewrite rules to drop the MD5 checksum from the resource URL before looking for the resource to serve up.

In any event, having the cache-busting strategy built into the framework would probably encourage more developers to use far-future expiration dates- which are GREAT for performance, but difficult to work with in the absence of a solid cache-busting strategy.

---

Affects: 3.2.1

Sub-tasks:

• Add setJavaScriptModuleLoaderMode (or similar) property to FingerprintResourceResolver [SPR-11865] #16484 Add setJavaScriptModuleLoaderMode (or similar) property to FingerprintResourceResolver

Issue Links:

• Enhance ResourceHttpRequestHandler with ResourceResolver strategy [SPR-10933] #15561 Enhance ResourceHttpRequestHandler with ResourceResolver strategy ("depends on")
• Enhance ResourceHttpRequestHandler with ResourceTransformer strategy [SPR-11800] #16420 Enhance ResourceHttpRequestHandler with ResourceTransformer strategy ("depends on")

Referenced from: commits d4a0e62, 4ca7d89

6 votes, 12 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

Thanks for the detailed suggestion. A specific concern would be to make sure the logic to identify the presence of an MD5 hash is very explicit and unambiguous to avoid corner cases that can lead to surprises. All in all it should be a nice feature.

[spring-projects-issues]

Neale Upstone commented

This would be a great feature. I think Matt Raible's article should give us some clues at to what ResourceVersionSource (as I'll call it) strategies other than MD5 we might need (I can see there also being ContextStartupTimestampResourceVersionSource and ManifestEntryResourceVersionSource).

I want this functionality on what I'm doing, so I'll implement it with a contrib in mind and update here.

[spring-projects-issues]

Neale Upstone commented

I'd suggest that #15097 will need addressing first to allow must-revalidate to be excluded.

[spring-projects-issues]

Dave Syer commented

You can also achieve the Handler side of this feature (part 2) with a Filter that strips a path prefix from "cacheable" asset paths. I would suggest a HandlerInterceptor, but #15283 makes that tricky to achieve generally for static assets.

On the View side (part 1), rather than using MD5 as a prefix I would suggest it might be sufficient to use a version label (so all assets change once per release). This is pretty easy to implement with a Filter or HandlerInterceptor adding that prefix to the model, so that a View can render it. This is a lot like a content delivery network would be used in an app, so it's kind of a lightweight alternative to that.

Personally I prefer not to use JSPs, so other View support would be needed. Adding the correct prefix to the model is a good step in the right direction.

Edit: Having read the Raible link from Neale's comment I think I was just paraphrasing that approach (although it could be made a lot simpler than the one used there).

[spring-projects-issues]

Neale Upstone commented

We've got a scenario where we have cache-busting along the above lines and we'll be looking to use the generated URLs in a controller, as we'll be generating entries for an HTML5 application cache manifest file to refer to cache busted resources (the app can fall back to offline).

I'd say that a good solution will give infrastructure to generate the URL both in JSP but within the controller itself. Somehow I think it goes without saying.. but now I've said it, I'll add the comment ;)

[spring-projects-issues]

Rossen Stoyanchev commented

Neale Upstone, see #15561. It doesn't provide enough detail but should give an idea. There will be new interfaces for resolving a URL path to a resource (e.g. foo-123.css to foo.css), as well the reverse, resolving a resource path to URL (e.g. foo.css to foo-123.css). You should be able to inject and use those from anywhere including controllers.

Currently we are considering a Filter-based approach that wraps the response and overrides the encodeURL method to render foo-123.css instead of foo.css. Since view tags or libraries usually call response.encodeURL, that would avoid the need for JSP-specific tags.

I expect to have some code in the master branch towards the end of this week.

[spring-projects-issues]

Brian Clozel commented

Hi Neale Upstone, here's a blog post with more details on this - including something for HTML5 appcache manifests.

[spring-projects-issues]

Neale Upstone commented

Thanks... I'd just discovered it only a few minutes ago. Really glad to see the step back that's been taken to provide a 'Great Leap Forwards'.

It looks really great. I'm looking forwards to making the switch. Really pleased you added in the App Cache support.

It was certainly worth waiting til the end of Rossen's week ;)

[spring-projects-issues]

Rossen Stoyanchev commented

:) yes famous last words. For what it's worth the code was ready that week but was pulled back after a quick trial with Sagan since computing content-based hashes without any form of cashing the result is too expensive. The extra time however was indeed important in more than one ways.

In all seriousness though it would be really great if you got a chance to have a closer look or try it in any form. The following weeks are the best window of opportunity for feedback!