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.
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.
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() ResourceResponse#setCacheDurationToMaximum() ResourceResponse#setCacheDuration(Duration) ResourceResponse#setCacheScope(WebResponse.CacheScope)
Timestamps in URLs
Any kind of resource reference that overrides
org.apache.wicket.request.resource.ResourceReference#getLastModified()
and returns a non-null value will be rendered with a timestamp in the url by wicket's resource mapper.
The file will look something like 'style-ts1282915831000.css' with '-ts' being the timestamp
prefix and the large number being the timestamp in milliseconds. So any change that affects
the last modification time will alter the resource's corresponding url, too.
This happens automatically for package resources or when using
where the
last modification time will be the lastModified timestamp of the file in the file system or JAR file
This for instance completely eliminates the dreaded "browser cache problem" probably any web developer knows
where he/she changes a stylesheet, deploys it but the customers browser (especially IE) still has an older
version in the cache but does not update instantly before hitting 'Reload'.