[CONF] Apache Wicket > Caching in Wicket 1.5

[confluence]

Caching in Wicket 1.5 Page added by Peter Ertl Things that changed from Wicket 1.4 to Wicket 1.5 Wicket always sends a Date header for pages and resources This header is important for proper caching and recommended 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. 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. 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 'no-cache' semantics was actually stronger in 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. All Wicket pages are by default non-cacheable and 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 | Add Comment