THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
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.
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.
For cacheable resources, caching is enabled more reliably and consistently
Caching is enabled by sending the following HTTP response headers:
Cache-Control: [public | private] , max-age=[timespan] Last-Modified: [timestamp] Expires: [timestamp]
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.
Resources extending
org.apache.wicket.request.resource.AbstractResource
use Cache-Control: private to avoid caching of potentially confidential information on public caches or proxies.
Resourced served from packages when using
<wicket:link>
or extending / using
org.apache.wicket.request.resource.PackageResource
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 special use cases you can enable or disable caching for a WebResponse with:
org.apache.wicket.request.http.WebResponse#disableCaching()
and
org.apache.wicket.request.http.WebResponse#enableCaching(Duration duration, WebResponse.CacheScope 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
