The no-cache setting in HTTP has always been a misunderstood beastie. The instinctual reaction for developers everywhere is to believe that it prevents caching or cache handling or some such myth.
This is not true.
By definition it merely forces caches to revalidate existing content before use (ie it tells the proxy to “be ultra, super-duper conservative. Do not send anything from cache without first contacting the server to double check it.”).
When sent on a client (browser) request:
- Pragma:no-cache instructs HTTP/1.0 caches to revalidate any cached response before using it.
- Cache-Control:no-cache instructs HTTP/1.1 caches to revalidate any cached response before using it.
- Pragma:no-cache only works for HTTP/1.1 caches when Cache-Control is missing.
- all other values of Pragma are undefined and to be ignored.
When sent on a server response:
- Pragma in all its forms has no meaning whatsoever. It must be ignored.
- Cache-Control:no-cache instructs HTTP/1.1 caches to revalidate this response every time it is re-used.
If you read those bullet points above very carefully you will notice that at no point is store mentioned. None whatsoever. The closest it gets is mentioning what to do with already-stored content (revalidate it). In fact the HTTP/1.1 specification goes as far as to say explicitly that responses with no-cache MAY be stored – provided the revalidation is done as above.
no-cache in Squid
The well-known squid versions of the past have all been HTTP/1.0 compliant and advertised themselves as HTTP/1.0 software. These proxies both looked for Pragma:no-cache headers and obeyed them:
- Squid being HTTP/1.0 that Pragma took precedence over Cache-Control.
- Due to lack of full HTTP/1.1 revalidation in very old versions Squid has traditionally treated no-cache in either header as if it were Cache-Control:no-store.
- Due to some old server software Pragma:no-cache on responses was treated as a mistaken form of Cache-Control:no-store.
Starting with version 3.2 Squid is advertising and attempting to fully support HTTP/1.1 specifications. This is a game changer.
All of the above is about to be up-ended, assumptions can be thrown away and some funky cool proxy behaviour allowed to take place.
Hiding in the background is the instruction that Pragma only applies when Cache-Control is missing from a request. We can ignore it – almost completely. When we do have to pay attention we only need to notice the no-cache value and can treat it as if we received Cache-Control:no-cache.
The other change is a potential game changer: The object being transfered is stored now, revalidated later.
Some implications from storing no-cache responses:
- servers can utilize 304 responses instead of generating new content. Saving a lot of bandwidth and CPU cycles.
- all those configuration hacks for ignoring or stripping no-cache are no longer needed. Also, the harm they do will become more visible as revalidation is skipped.
- cache HIT ratio can potentially rise above 50% for forward proxies. As a side effect of the HIT counting market a large portion of web traffic is utilizing no-cache instead of no-store or private. This large portion is cacheable but until now Squid has been dropping it.
Before the marketing department panics about the end of the world lets be clear on one important point:
revalidation means every client request will still reach the end server doing HIT counting, traffic control, whatever – but in a way which allows 304 bandwidth optimization on the responses.
Do not expect a sudden rise of TCP_HIT in the proxy logs though. It is more likely to show up as TCP_REFRESH_HIT or the nasty TCP_REFRESH_MODIFIED/TCP_REFRESH_MISS which is produced by broken web applications always sending out new unchanged content.