[CONF] Apache Wicket > Caching in Wicket 1.5

[confluence]

Caching in Wicket 1.5 Page edited by Peter Ertl Changes (22) h2. Things that changed from Wicket 1.4 to Wicket 1.5 h3. Wicket always sends a *Date* *'Date'* HTTP response header for pages and resources This header is important for proper caching and recommended in general by RFC-2616. [RFC-2616|http://www.ietf.org/rfc/rfc2616.txt] . Especially when using *Expires* or *Last-Modified* the browser has a server-based time to refer to and calculate durations (e.g. until cache expiry) and such. h3. Caching For non-cacheable resources, caching is disabled more reliably and consistently Caching is uniformly disabled now by sending the following HTTP response headers: Cache-Control: no-cache, no-store Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache The 'Pragma' header is relevant for HTTP/1.0 client. HTTP/1.1 client usually only care about 'Cache-Control'. The 'no-cache' value does not, as the name indicates, forbid caching but only means the client has to revalidate the previous response with the origin server before reusing it. However the semantics of this header changed as so many people used it incorrectly. {code} Cache-Control: no-cache, no-store Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache {code} see: http://stackoverflow.com/questions/1046966/whats-the-difference-between-cache-control-max-age0-and-no-cache The *Pragma* header is relevant for HTTP/1.0 clients. The 'no-store' value is effectively prohibiting any kind of storage of the web response and since the previous change of 'no-cache' semantics was actually stronger in prohibiting caching. The *Cache-Control* is is important for modern clients supporting HTTP/1.1. The *no-cache* value does not, as the name indicates, forbid caching but only means "the client has to revalidate the previous response with the origin server before reusing it". However the semantics of this header changed previously as so many people used it incorrectly. We are not sending 'Cache-Control: must-revalidate' anymore since it implies the resource can theoretically be cached when in fact it must not. see: [http://stackoverflow.com/questions/1046966/whats-the-difference-between-cache-control-max-age0-and-no-cache] The 'Expires' header is one more protection against caching. All Wicket pages are by default non-cacheable and use these headers. The *no-store* value is effectively prohibiting any kind of storage of the web response and since the previous change of the semantics of *no-cache* was actually stronger in means of prohibiting caching. We are +not+ sending *Cache-Control: must-revalidate* anymore since it implies the resource can theoretically be cached when in fact it must not. The *Expires* header is one more protection against caching, especially fo client that do not understand *Cache-Control*. All Wicket pages are by default non-cacheable as in 1.4 and now use these headers. - Caching is enabled by sending the following HTTP response headers: Last-Modified: [timestamp] Cache-Control: [public |private], max-age=[timespan] Last-Modified: Expires: [timestamp] Expires: [timestamp] Vary: Accept-Encoding In the past Wicket did not always set these headers consistently, now it should. The 'Cache-Control: public' part means the response may be cached by public caches and proxies. When using 'Cache-Control: private' responses may only be cached by the browser and not by any public cache. Wicket resource by default use 'private' to avoid caching of confidential resource in public. Be aware that some (older?) versions of Firefox do not cache any SSL content when using 'private'. ... In special cases you can enable or disable caching for a WebResponse with: \#org.apache.wicket.request.http.WebResponse#disableCaching() // disable caching \#org.apache.wicket.request.http.WebResponse#enableCaching(Duration duration, WebResponse.CacheScope scope) // enable caching, specifying duration and cache scope - Manual control of caching for resources when using org.apache.wicket.request.resource.ResourceResponse from org.apache.wicket.request.resource.AbstractResource you can use: ResourceResponse#disableCaching() // make resource response non-cacheable ResourceResponse#setCacheDurationToMaximum() // for maximum recommended cache duration based on RFC-2616 ResourceResponse#setCacheDuration(Duration) // to make resource cacheable for a fixed duration ResourceResponse#setCacheScope(WebResponse.CacheScope) // to configure 'public' or 'private' caching Full Content Things that changed from Wicket 1.4 to Wicket 1.5 Wicket always sends a 'Date' HTTP response header for pages and resources This header is important for proper caching and recommended in general by RFC-2616 . Especially when using Expires or Last-Modified the browser has a server-based time to refer to and calculate durations (e.g. until cache expiry) and such. For non-cacheable resources, caching is disabled more reliably and consistently Caching is uniformly disabled now by sending the following HTTP response headers: Cache-Control: no-cache, no-store Expires: Thu, 01 Jan 1970 00:00:00 GMT Pragma: no-cache The Pragma header is relevant for HTTP/1.0 clients. The Cache-Control is is important for modern clients supporting HTTP/1.1. The no-cache value does not, as the name indicates, forbid caching but only means "the client has to revalidate the previous response with the origin server before reusing it". However the semantics of this header changed previously as so many people used it incorrectly. see: http://stackoverflow.com/questions/1046966/whats-the-difference-between-cache-control-max-age0-and-no-cache The no-store value is effectively prohibiting any kind of storage of the web response and since the previous change of the semantics of no-cache was actually stronger in means of prohibiting caching. We are not sending Cache-Control: must-revalidate anymore since it implies the resource can theoretically be cached when in fact it must not. The Expires header is one more protection against caching, especially fo client that do not understand Cache-Control. All Wicket pages are by default non-cacheable as in 1.4 and now use these headers. Caching is enabled by sending the following HTTP response headers: Cache-Control: public , max-age=timespan Last-Modified: timestamp Expires: timestamp Vary: Accept-Encoding In the past Wicket did not always set these headers consistently, now it should. The 'Cache-Control: public' part means the response may be cached by public caches and proxies. When using 'Cache-Control: private' responses may only be cached by the browser and not by any public cache. Wicket resource by default use 'private' to avoid caching of confidential resource in public. Be aware that some (older?) versions of Firefox do not cache any SSL content when using 'private'. The 'Vary: Accept-Encoding' is required to make caches aware that different versions of the resource could exist in cache (e.g. when a cache supports 'gzipped' and 'uncompressed' resources). Wicket redirects explicitly disabled for caching As experienced in nginx-0.7 caches, when set up very aggressively, may cache server side redirects (http status = 302). As Wicket relies on dynamic redirects it explicitly disables caching in '302' responses. Manual control of caching for web responses In special cases you can enable or disable caching for a WebResponse with: #org.apache.wicket.request.http.WebResponse#disableCaching() // disable caching #org.apache.wicket.request.http.WebResponse#enableCaching(Duration duration, WebResponse.CacheScope scope) // enable caching, specifying duration and cache scope Manual control of caching for resources when using org.apache.wicket.request.resource.ResourceResponse from org.apache.wicket.request.resource.AbstractResource you can use: ResourceResponse#disableCaching() // make resource response non-cacheable ResourceResponse#setCacheDurationToMaximum() // for maximum recommended cache duration based on RFC-2616 ResourceResponse#setCacheDuration(Duration) // to make resource cacheable for a fixed duration ResourceResponse#setCacheScope(WebResponse.CacheScope) // to configure 'public' or 'private' caching Change Notification Preferences View Online | View Changes | Add Comment