Details

    • Type: Sub-task
    • Status: Closed
    • Priority: Minor
    • Resolution: Complete
    • Affects Version/s: 3.0.2
    • Fix Version/s: 4.2 RC1
    • Component/s: Web
    • Labels:
    • Last commented by a User:
      false

      Description

      As per The HTTP 1.1 RFC (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1) Cache-Control HTTP header can have keywords public or private specified.

      One would use the public keyword for cacheable resources that are behind HTTP authentication – a common case would be static javascript or image files that not accessible to general public. An even stronger case could be made for JSON/XML data intended for an AJAX client behind HTTP authentication that still wants to cache the response.

      The private keyword is intended in cases where privacy of the cached data should be enforced – for example for cached profile pages of the user.

      These improvements would benefit applications that want comply with the recent trends in web site optimizations, such as the ones outlined in the best practices for caching section of Google's page speed project (http://code.google.com/speed/page-speed/docs/caching.html).

        Issue Links

          Activity

          Hide
          mschipperheyn marc schipperheyn added a comment -

          No, in one of my earlier comments I talked about using a style such as used in the WebContentGenerator to express these kinds of configurations. This allows you to manage your settings without hardcoding them at the controller level such as SPR-8550 suggests.

          Show
          mschipperheyn marc schipperheyn added a comment - No, in one of my earlier comments I talked about using a style such as used in the WebContentGenerator to express these kinds of configurations. This allows you to manage your settings without hardcoding them at the controller level such as SPR-8550 suggests.
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          I agree interceptor-style should be preferred for configuring caching. The main reason for even considering @CacheControl in my mind is to provide a more encapsulated alternative for frameworks or services built on Spring MVC like Spring Social.

          I wonder if having an annotation isn't going too far. Perhaps we should change the scope for SPR-8550 to be more along the lines of how we support not-modified with an etag in @MVC controller methods.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - I agree interceptor-style should be preferred for configuring caching. The main reason for even considering @CacheControl in my mind is to provide a more encapsulated alternative for frameworks or services built on Spring MVC like Spring Social. I wonder if having an annotation isn't going too far. Perhaps we should change the scope for SPR-8550 to be more along the lines of how we support not-modified with an etag in @MVC controller methods.
          Hide
          bclozel Brian Clozel added a comment -

          Those changes will be available for WebContentGenerator.
          Check out SPR-11792, it lists all changes to be made in that space. Feel free to comment there as well if the description is incomplete.

          Show
          bclozel Brian Clozel added a comment - Those changes will be available for WebContentGenerator. Check out SPR-11792 , it lists all changes to be made in that space. Feel free to comment there as well if the description is incomplete.
          Hide
          w_c_smith Christopher Smith added a comment -

          As a note, the ResourceHandlerRegistry#addResourceHandler builder syntax, which was extended in 4.1 with strategy-based resource resolvers, should have an easy mechanism to set Cache-Control: public in addition to max-age (with setCachePeriod). I'm slowly getting cache busting working with my entire pipeline, but there's no way to tell MVC that all those static resources are publicly cacheable.

          Show
          w_c_smith Christopher Smith added a comment - As a note, the ResourceHandlerRegistry#addResourceHandler builder syntax, which was extended in 4.1 with strategy-based resource resolvers, should have an easy mechanism to set Cache-Control: public in addition to max-age (with setCachePeriod ). I'm slowly getting cache busting working with my entire pipeline, but there's no way to tell MVC that all those static resources are publicly cacheable.
          Hide
          bclozel Brian Clozel added a comment -

          A new CacheControl builder class allows the "public" and "private" Cache-Control directives.

          Such a property can be configured like this for handling resources:

          @Override
          public void addResourceHandlers(ResourceHandlerRegistry registry) {
              CacheControl cc = CacheControl.maxAge(10, TimeUnit.DAYS)
                                            .cachePublic();
              registry.addResourceHandler("/resources/**")
                          .addResourceLocations("classpath:/resources/")
                          .setCacheControl(cc);

          See SPR-11792 for more details.

          Show
          bclozel Brian Clozel added a comment - A new CacheControl builder class allows the "public" and "private" Cache-Control directives. Such a property can be configured like this for handling resources: @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { CacheControl cc = CacheControl.maxAge( 10 , TimeUnit.DAYS) .cachePublic(); registry.addResourceHandler( "/resources/**" ) .addResourceLocations( "classpath:/resources/" ) .setCacheControl(cc); See SPR-11792 for more details.

            People

            • Assignee:
              bclozel Brian Clozel
              Reporter:
              zregvart Zoran Regvart
              Last updater:
              St├ęphane Nicoll
            • Votes:
              11 Vote for this issue
              Watchers:
              23 Start watching this issue

              Dates

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