Details

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

      Description

      Even though WebContentInterceptor can be used to declare when and how cache-control headers are set in a response, it isn't as straightforward or consistent with the @Controller model.

      I propose an annotation-based option for declaring when cache-control headers are added to a response. For example, a general-purpose @CachePolicy annotation might be used like this:

      @CachePolicy(maxAge=60)
      @RequestMapping(value="/headlines", method=RequestMethod.GET)
      public String showHeadlines() { ... }

      Also, perhaps a more specific-purpose @PreventCaching annotation might declare that a response include the headers currently added by WebContentGenerator's preventCaching() method.

      These two annotations are just suggestions--I'd be interested in any solution that allows for declarative cache policies at the request method level.

        Issue Links

          Activity

          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          This would be useful in cases where configuring an interceptor is not ideal (e.g. a framework built on Spring MVC). For Spring MVC applications WebContentInterceptor should be sufficient and more centralized.

          Instead of @PreventCaching, we could take maxAge=0 to mean the same. That would also be consistent with how WebContentGenerator works.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - This would be useful in cases where configuring an interceptor is not ideal (e.g. a framework built on Spring MVC). For Spring MVC applications WebContentInterceptor should be sufficient and more centralized. Instead of @PreventCaching, we could take maxAge=0 to mean the same. That would also be consistent with how WebContentGenerator works.
          Hide
          axe-felix Felix Barnsteiner added a comment -
          Show
          axe-felix Felix Barnsteiner added a comment - I would suggest to do this simmilar to JAX-RS 2.0: http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/core/CacheControl.html
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment - - edited

          I've updated the title (was: "Declarative cache policy for @Controller handler methods") to be more flexible with regards to the final solution. Here is one alternative approach for example that is more in line with the way we support not modified with etag for controller methods. Also the new ResponseEntity builder option SPR-11752 may be a natural place to consider adding cache control support.

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - - edited I've updated the title (was: "Declarative cache policy for @Controller handler methods") to be more flexible with regards to the final solution. Here is one alternative approach for example that is more in line with the way we support not modified with etag for controller methods. Also the new ResponseEntity builder option SPR-11752 may be a natural place to consider adding cache control support.
          Hide
          bclozel Brian Clozel added a comment -

          There are now several ways to handle HTTP caching at the controller level:

          • using ResponseEntity when such a type is returned by the controller
          • using WebRequest otherwise

          This is described in the dedicated section of the reference documentation.
          See also the new CacheControl class Javadoc.

          See SPR-11792 for more details.

          Show
          bclozel Brian Clozel added a comment - There are now several ways to handle HTTP caching at the controller level: using ResponseEntity when such a type is returned by the controller using WebRequest otherwise This is described in the dedicated section of the reference documentation . See also the new CacheControl class Javadoc. See SPR-11792 for more details.
          Hide
          michael-o Michael Osipov added a comment -

          I fail to see how this was reasonably resolved. There is no annotation for this. Using ResponseEntity along with CacheControl means to change all method signatures. Is that the proposed solution as an alternative to WebContentInterceptor?

          Show
          michael-o Michael Osipov added a comment - I fail to see how this was reasonably resolved. There is no annotation for this. Using ResponseEntity along with CacheControl means to change all method signatures. Is that the proposed solution as an alternative to WebContentInterceptor ?
          Hide
          bclozel Brian Clozel added a comment -

          Hi Michael Osipov

          Here is my current understanding about this:

          • if your application needs a broad, static cache configuration, then the WebContentInterceptor is probably your best bet; you can configure common cache directives for parts of your URL space. This configuration happens in a single place and is easily understandable.
          • if your application needs more fine-grained cache configuration, then ResponseEntity is the way to go. Indeed, many cache directives depend on the resource itself: "Etag", "Last-Modified", "Cache-Control: public/private/max-age/etc". Many of those choices can't be made without making big assumptions about the served resources and the decision is quite local actually.

          Now we were considering @CacheControl annotations but we thought that this would be limiting quite quickly, since cache directives values are often derived from the served resource. How would you support that, besides very complex and error-prone SpEL expressions?

          There are also other ways to globally alter those cache directives (by using @SessionAttributes for example), and giving a way to override that at the controller level is probably the best way to give the full power to the developers, and not wonder which cache directives will eventually show up in the response.

          What are you missing with the current model?
          How would you address this?

          Show
          bclozel Brian Clozel added a comment - Hi Michael Osipov Here is my current understanding about this: if your application needs a broad, static cache configuration, then the WebContentInterceptor is probably your best bet; you can configure common cache directives for parts of your URL space. This configuration happens in a single place and is easily understandable. if your application needs more fine-grained cache configuration, then ResponseEntity is the way to go. Indeed, many cache directives depend on the resource itself: "Etag" , "Last-Modified" , "Cache-Control: public/private/max-age/etc" . Many of those choices can't be made without making big assumptions about the served resources and the decision is quite local actually. Now we were considering @CacheControl annotations but we thought that this would be limiting quite quickly, since cache directives values are often derived from the served resource. How would you support that, besides very complex and error-prone SpEL expressions? There are also other ways to globally alter those cache directives (by using @SessionAttributes for example), and giving a way to override that at the controller level is probably the best way to give the full power to the developers, and not wonder which cache directives will eventually show up in the response. What are you missing with the current model? How would you address this?

            People

            • Assignee:
              bclozel Brian Clozel
              Reporter:
              habuma Craig Walls
              Last updater:
              Brian Clozel
            • Votes:
              10 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 21 weeks, 5 days ago