Spring Framework
  1. Spring Framework
  2. SPR-7116

Add ResourceHttpRequestHandler for efficiently serving static resouces

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.0.4
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      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.

        Issue Links

          Activity

          Show
          Keith Donald added a comment - - edited 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/
          Hide
          Keith Donald added a comment -

          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

          Show
          Keith Donald added a comment - 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
          Hide
          Jeremy Grelle added a comment -

          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.

          Show
          Jeremy Grelle added a comment - 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.
          Hide
          Juergen Hoeller added a comment -

          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

          Show
          Juergen Hoeller added a comment - 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
          Hide
          Keith Donald added a comment -

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

          Show
          Keith Donald added a comment - Juergen Just a heads up. The JAF handling code was lifted from ContentNegotiatingViewResolver.

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Keith Donald
              Last updater:
              Trevor Marshall
            • Votes:
              9 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                3 years, 37 weeks, 3 days ago