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:
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.
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 on clients that do not understand Cache-Control.
All Wicket pages are by default non-cacheable as in 1.4 and now use these headers.
For cacheable resources, caching is enabled more reliably and consistently
Caching is enabled by sending the following HTTP response headers:
In the past Wicket did not always set these headers consistently, now it should.
When using Cache-Control: public part means the response may be cached by any (public) caches and proxies.
When using Cache-Control: private responses may only be cached by the browser and not by any public cache.
use Cache-Control: private to avoid caching of potentially confidential information on public caches or proxies.
Resourced served from packages when using
or extending / using
are using Cache-Control: public by default.
Be aware that some (older?) versions of Firefox do not cache any SSL content when using Cache-Control: private (see here ). If you are can ensure resources are only served over SSL you can safely set Cache-Control:public as caches in between will not be able to cache them.
Wicket redirects explicitly disabled for caching
As experienced e.g. in nginx (version 0.7.67 or so) some caches, when set up very aggressively, may cache server side redirects (statuscode = 302 temporarily moved). As Wicket heavily relies on dynamic redirects it explicitly disables caching now.
Manual control of caching for web responses
In custom use cases you can enable caching for a WebResponse with:
But you must also override this method of WebPage (at least in Wicket 1.5.4), per bug https://issues.apache.org/jira/browse/WICKET-4357:
Or, you can disable caching with:
Manual control of caching for resources
you can use
Long-Term caching for package resources
Package resources are now fully cacheable for one year (maximum value recommended in RFC-2616). Since the resource urls contain a fingerprint in the filename that changes when the related resource data changes there will be no stale cache hits. So you get best network performance and reliable, instant cache invalidation.
for more details see https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-inIResourceSettingsmethodsetAddLastModifiedTimeToResourceReferenceUrl%28%29hasbeenreplacedbyIResourceCachingStrategy for details...