return builder . build ();
In this example, we initialize a java.util.Date object and pass it to the ResponseBuild-
er.expires() method. This method sets the Expires header to the string date format the
HTTP caching semantics were completely redone for the HTTP 1.1 specification. The spe-
cification includes a much richer feature set that has more explicit controls over browser and
CDN/proxy caches. The idea of cache revalidation was also introduced. To provide all this
new functionality, the Expires header was deprecated in favor of the Cache-Control head-
er. Instead of a date, Cache-Control has a variable set of comma-delimited directives that
define who can cache, how, and for how long. Let's take a look at them:
The private directive states that no shared intermediary (proxy or CDN) is allowed to
cache the response. This is a great way to make sure that the client, and only the client,
caches the data.
The public directive is the opposite of private . It indicates that the response may be
cached by any entity within the request/response chain.
Usually, this directive simply means that the response should not be cached. If it is
cached anyway, the data should not be used to satisfy a request unless it is revalidated
with the server (more on revalidation later).
A browser will store cacheable responses on disk so that they can be used after a browser
restart or computer reboot. You can direct the browser or proxy cache to not store cached
data on disk by using the no-store directive.
Some intermediary caches have the option to automatically transform their cached data to
save memory or disk space or to simply reduce network traffic. An example is compress-
ing images. For some applications, you might want to disallow this using the no-trans-