Caching in Wicket 1.5

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 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:

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 custom use cases you can enable caching for a WebResponse with:

org.apache.wicket.request.http.WebResponse#enableCaching(Duration duration, WebResponse.CacheScope scope)

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:

protected @Override void setHeaders( org.apache.wicket.request.http.WebResponse response ) {} // do nothing

Or, you can disable caching with:

org.apache.wicket.request.http.WebResponse#disableCaching()

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

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...

Child pages