Disabling client cache from Jetty server for REST requests

Question

I have a REST Java server implemented with Jersey running on Jetty. It seems that certain browsers (IE7) internally caches all requests made to the server.

What I would like to do is to send a certain HTTP header in the response from the REST server indicating the browser that it shouldn't cache that response, and so will query the server again the next time it needs access to that resource.

Any ideas on how to configure Jersey/Jetty for this? Or the only way to configure it is client-side?

Answer 1

There's nothing you can do about rogue clients, but Jetty can send the appopriate HTTP headers. Try here for info on configuring the Last-Modified and Cache-Control headers.

Answer 2

On the server side you can try this if you have access to the response (you might be able to do it through filters).

response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Expires", "0");

Another trick you can try on the client side is to add an superfluous argument to the url like "http://www.company.com/services/staff?id=xxx&requestTime="+(new Date()).getTime(); This way the url being request is different every time and it can't be cached.

Answer 3

response.setHeader("Pragma", "no-cache");

No, No. No!

The use of the pragma header to disabling client side caching is wrong, it's a request header and has zero effect on the response.

http://www.mnot.net/cache_docs/#PRAGMA

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32

Also, setting Expires: 0 isn't correct, Expires should be a date, not a number of seconds, however this will work as an invalid http date is interpreted as "already expired"

http://www.mnot.net/cache_docs/#EXPIRES

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

Answer 4

@Dave Cheney: well, what I understand from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 is that Cache-control makes sense for the request as well as for the response. And when the response is a cache-controled response, it's a specification for what the client (browser) should do with the resource (see next section, 14.9.1).

@all: Also, in section 14.21 of the same document it's specified that the Expires header set on 0 means 'invalid date' and can be ignored by the clients. And my tests with sending an expires date to 1 jan 1970 (timestamp 0) causes nothing but ignore from IE (and ff for that matter), which will still cache the response.

My solution was to send the current date for the Expires field, which is what the spec says.