Add ResourceHttpRequestHandler for efficiently serving static resouces [SPR-7116]

[spring-projects-issues]

Keith Donald opened SPR-7116 and commented

The Spring JavaScript module of the Web Flow project contains a ResourceServlet that efficently serves static resources such as .css and .js files. This servlet has proven generally useful and, as a user, I'd like this functionality available in Spring Framework's core web support. Specifically:

• I'd like this functionality to be configurable within a Spring MVC DispatcherServlet, without requiring another servlet to be configured in web.xml. This simplifies setup and also allows for greater configuration control with the Spring MVC namespace.

• Caching should be aggressive. All resources served up should be cached with a far out expiration date (e.g. 1 year).

• Compression should be applied to text-based resources e.g. .css, .js, .json, and .xml files (should be possible to disable)

• Minification should be applied to text-based resources where possible e.g. .js (should be possible to disable)

• Resource bundling should be supported. This provides the ability to load multiple resources in one HTTP request, which can improve performance.

• Resource versioning should be supported. This causes clients to refresh cached resources when a new version of the application is deployed. This prevents clients from working with stale content after deployment of a new version. (should be possible to disable, when disabled no caching should be performed)

• It should be possible to serve resources out of the webapp root as well as jar file bundles.

• The ResourceHandler should aim to be compatible with JSF 2.0 resource handling as far as possible (we should not make compromises but we shouldn't be different when we can align).

The ResourceHandler should also be capable of being the "default handler" for the DispatcherServlet. This would provide a static resource handling fallback similar to how the Servlet Container works.

---

Affects: 3.0.2

Attachments:

• ResourceHttpRequestHandler.java (9.01 kB)
• ResourceHttpRequestHandlerTests.java (6.44 kB)

Sub-tasks:

• Add support for compressing resources [SPR-7140] #11799 Add support for compressing resources

Issue Links:

• Improve handling of static resources [SPR-7400] #12058 Improve handling of static resources ("is depended on by")
• Move org.springframework.js.resource.ResourceServlet to Spring framework core [SPR-6641] #11307 Move org.springframework.js.resource.ResourceServlet to Spring framework core ("supersedes")

9 votes, 16 watchers

[spring-projects-issues]

Keith Donald commented

Design of initial support:

A single Spring MVC namespace element:

<mvc:resources />

• Registers a HttpResourceRequestHandler mapped to "/resources" serving up cached & compressed resources located in the $webappRoot/resources directory.

• Supports getting versioned resources via HTTP GET /resources/{version}/{resource} e.g. GET/resources/1.0.0/styles/main.css.

• Supports getting a resource bundle via HTTP GET /resources/{version}/{resource,res2Name,res3Name,...} e.g. GET /resources/1.0.0/styles/main.css,sub.css,sub2.css.

[spring-projects-issues]

Mike Youngstrom commented

It would be nice if enabling/disabling compression was an attribute on the handler. It can be enabled by default.

[spring-projects-issues]

Keith Donald commented

Initial version of a ResourceHttpRequestHandler that meets all these requirements but compression. Compression is a large enough chunk of work where it should be addressed as an improvement in a separate JIRA.

[spring-projects-issues]

Keith Donald commented

Plugged the initial version into the Petcare reference sample app here: https://src.springframework.org/svn/spring-samples/petcare/

[spring-projects-issues]

Zoran Regvart commented

I would propose two improvements for the initial implementation:

• for mime-type determination one useful feature would be to also consult the ServletContext (via getMimeType method), this allows for specifying the mime types in web.xml (in the <mime-mapping> element)
• I think that the implementation would benefit if it were to extend the org.springframework.web.servlet.support.WebContentGenerator for the caching configuration (via the checkAndPrepare method), and also implement org.springframework.web.servlet.mvc.LastModified to keep it in line with the spring-mvc

thanks

Zoran

[spring-projects-issues]

Keith Donald commented

Various articles on resource combining:
http://www.ejeliot.com/blog/72
http://bestpractical.typepad.com/worst_impractical/2006/09/smart_caching_f.html
http://code.google.com/p/php-squish/
http://www.expectationgap.com/posts/10
http://www.sitepoint.com/blogs/2007/04/10/faster-page-loads-bundle-your-css-and-javascript/
http://www.artweb-design.de/2007/4/13/rails-plugin-blazing-fast-page-loads-through-bundled-css-and-javascript
http://www.maxkiesler.com/2007/11/04/how-to-minimize-your-javascript-and-css-files-for-faster-page-loads/
http://www.ericmmartin.com/comparison-of-javascript-compression-methods/
http://stackoverflow.com/questions/702907/what-are-some-good-css-and-js-minimizers-for-production-code

Build-time:
http://www.samaxes.com/2009/05/combine-and-minimize-javascript-and-css-files-for-faster-loading/

[spring-projects-issues]

Keith Donald commented

Another suggestion: resource/<name-1>[,name n].[ext] format instead of resource/<name-1.ext>,<name-n.ext> format e.g. /resources/foo,bar,baz.css vs /resources/foo.css,bar.css,baz.css

[spring-projects-issues]

Jeremy Grelle commented

Initial support provides functional parity with the current Spring JS ResourceServlet (with the exception of resource combining) is being considered for inclusion in Spring 3.0.4. The scope has thus far been cut down to include only:

• Configuration within the DispatcherServlet context via a new 'mvc:resources' namespace tag

• Aggressive caching headers

• Configurable GZip compression of text/* mime types when supported by the client

• Ability to serve resources from the web app root (the default) as well as from the classpath (via user opt-in configuration)

• Handling of requests for static resources not mapped to the /resources/* (or otherwise configured) path by forwarding to the Servlet container's default Servlet

Additional enhancements on the list will be re-considered for 3.1.

[spring-projects-issues]

Juergen Hoeller commented

I've revised ResourceHttpRequestHandler quite a bit and committed another cut now. It lives in a "web.servlet.resource" now (instead of "web.servlet.resources"), and builds on extended functionality in the Resource abstraction (with respect to last-modified and content-length headers).

One remaining issue is MIME type resolution: I've kept the ServletContext-based resolution but removed the JAF-based resolution for the time being, since I strongly feel that it doesn't belong there (neither JAF in the first place nor the JavaMail support's mime.types file in particular). If we got specific well-known MIME types that servlet containers typically don't support (and that we don't want people to explicitly declare in web.xml either), then we should bake those into ResourceHttpRequestHandler directly - as a static Map or the like.

Juergen

[spring-projects-issues]

Keith Donald commented

Juergen
Just a heads up. The JAF handling code was lifted from ContentNegotiatingViewResolver.