...
- When a portlet sets an ETag on any response with an expiration time the portal caches the content using the ETag, until the expiration time passes any subsequent request for the same ETag results in immediate replay from cache
- One the expiration time for an ETagged response has passed the portlet is consulted to see if the ETag is still valid for the request, if the portlet returns true the content is replayed and the cache expiration updated.
- On resource responses the ETag is passed to the browser as the ETag HTTP header
| Warning |
|---|
Chrome has some caching issues when using eTags with ResourceRequests (subsequent eTag hits return empty response from cache). See the latest CalendarPortlet code for methods of overcoming this. (Jan 2014) |
More Information
For a complete description of how portlet caching works it is recommended to read section PLT.22 of the JSR-286 specification.
...
| Tip |
|---|
This can be a pain when doing local development because changes to JavaScript or CSS files require restarting Tomcat or other processesprocedures to clear the spring-managed page cache. In these cases one solution to speed development and allow you to see changes to static resources immediately is to temporarily comment out the url pattern from the filter-mapping (but don't check it in). |