Avoid caching of the http responses

Question

What is the definitive solution for avoid any kind of caching of http data? We can modify the client as well as the server - so I think we can split the task between client and the server.

Client can append to each request a random parameter http://URL/path?rand=6372637263 – My feeling is that using only this way it is not working 100% - might be there are some intelligent proxies, which can detect that… On the other side I think that if the URL is different from the previous one, the proxy cannot simply decide to send back some cached response.

On server can control a bunch of HTTP headers:

Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

Any comments to this, what is the best approach?

Solution 1

Server-side cache control headers should look like:

Expires: Tue, 03 Jul 2001 06:00:00 GMT
Last-Modified: {now} GMT
Cache-Control: max-age=0, no-cache, must-revalidate, proxy-revalidate

Avoid rewriting URLs on the client because it pollutes caches, and causes other weird semantic issues. Furthermore:

• Use one Cache-Control header (see rfc 2616) because behaviour with multiple entries is undefined. Also the MSIE specific entries in the second cache-control are at best redundant.

• no-store is about data security. (it only means don't write this to disk - caches are still allowed to store the response in memory).

• Pragma: no-cache is meaningless in a server response - it's a request header meaning that any caches receiving the request must forward it to the origin.

• Using both Expires (http/1.0) and cache-control (http/1.1) is not redundant since proxies exist that only speak http/1.0, or will downgrade the protocol.

• Technically, the last modified header is redundant in light of no-cache, but it's a good idea to leave it in there.

• Some browsers will ignore subsequent directives in a cache-control header after they come across one they don't recognise - so put the important stuff first.

Solution 2

Adding header

Cache-control: private

guarantees, that gataway cache won't cache such request.

I'd like to recommend you Fabien Potencier lecture about caching: http://www.slideshare.net/fabpot/caching-on-the-edge

Comments

[STeN]

Cool presentation. Thanks for that.

[symcbean]

I notice that people are still looking at this answer. Like all things on the internet it is a little dated - pushstate does allow for client side tinkering with URLs - but exercise extreme caution! Do have a look at mod_pagespeed too. This handes a lot of URL rewriting and merging of content on the server. Other than that, the rest of the content in my answer still holds up.

[KrekkieD]

this is not exactly true. In my experience Akamai CDN tends (tended?) to ignore this and will happily still cache your private data for you.

[lf215]

can you explain Expires: Tue, 03 Jul 2001 06:00:00 GMT - should this be Expires: Thu, 01 Jan 1970 00:00:00 GMT ?

[symcbean]

@If215: any time in the past should prevent caching. However when you start talking to lots of computers you'll find people with flat clock batteries, mis-configured timezones and other weirdness.

[Rahly]

Note: Although this is good thing, GET's can still be cached by proxy's using their own rules. Meaning, they don't have respect your headers. EVER.

[symcbean]

According to the spec, proxies inherit the same obligations with regarding to caching that a browser cache is subject to. In addition there are some directive specifically targeting the behaviour of intermediate caches (as caching proxies are described in the specs). Agreed that not all devices conform to the rules, but your statement is inaccurate and misleading