X-Cache and X-Cache-Lookup headers explained

Vide Software, Tips, Web systems

Ok, maybe you have no problems while dealing with web caches but I (and my workmates as well :P ) do, so here it goes this post.

Let imagine you are behind a classical transparent proxy on port 80 and you’re visiting a web site running an internal web cache (so, another proxy). If you inspect your HTTP headers looking for some info, you can find two lines that look like this, given domain.tld as the local website and proxy.local as your internal transparent proxy.


X-Cache HIT from proxy.domain.tld, MISS from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, MISS from proxy.local:3128

What does this mean? That this is the first time you visit that website (MISS from proxy.local) and that their proxy has a valid copy of the page in its cache (X-Cache HIT proxy.domain.tld). I’ll explain X-Cache-Lookup meaning later


X-Cache MISS from proxy.domain.tld, MISS from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, HIT from proxy.local:3128

Now, we’ve just refreshed the page (F5, Ctrl+R, you name it) but wait… what’s happening? It seems both proxies are not serving any page, and we’ve got two mysterious HITs in Cache-Lookup. Well, it’s very simple. We are not counting another level of cache. The browser web cache. So, the page now is not pulled at all from the net, instead Firefox (or your web browser of choice) is using it’s own cache to show the page, so we’ve got two MISSes in X-Cache but nonetheless both proxies are telling us that they would send the cache copy if asked. So, if you’re debugging your proxy system, it means it’s working correctly.

Now, what if we empty Firefox’s cache ??
Here it is:

X-Cache MISS from proxy.domain.tld, HIT from proxy.local
X-Cache-Lookup HIT from proxy.domain.tld:3128, HIT from proxy.local:3128

Our transparent proxy has got the page we need so it sends it to us (HIT from proxy.local), the remote proxy doesn’t need to do anything and both could send the page in case we want.

Although it could seem complicated, once you get it it’s very very simple, and you can easily nest more and more cache levels.

14 thoughts on “X-Cache and X-Cache-Lookup headers explained”

  1. So what does that
    X-Cache MISS from domain.com
    X-Cache-Lookup HIT from domain.com:80
    mean?

    When using FireBug to check the headers (the NET tab) the locally cached files do not appear when there’s no need to verify them.

    Reply

  2. Sorry for the delay in the answer… as said, it means that the remote proxy WOULD serve you a cached copy but your Firefox already has a copy, so what you’re viewing right now is the previously locally cached image (sitting in your hard disk). If you clean the Firefox’s cache and do a refresh, you should see HIT/HIT

    Reply

  9. Start by explaining what these headers and their possible values mean. You started your article not from basics but the advanced explanation of these headers. Thus, anyone like me who is looking for definition of these headers find this article useless. Chances are that if someone has the basic knowledge to comprehend your article, he already knows this stuff and hence it is useless to him too. Hope you get the point.

    Reply

    • +1 on Amit’s comment. This is a great post already, but we can definitely use a post that goes more to the basics in a “Dummies Guide to (Squid) caching” way. Or is there such a book on that already?

      Reply

  10. Would it be ok to assume the following?

    X-Cache HIT = content returned is currently in the server’s cache, MISS = not in cache currently
    X-Cache-Lookup HIT = requested content was in server’s cache, MISS = was not in cache

    we use Squid and I see that when sending request header “Pragma: no-cache”, the X-Cache becomes a MISS as we purged cache while making the request, but X-Cache-Lookup remains a HIT if it was previously a HIT. And supposedly you clear that via the Squid server management and not via any request headers?

    I don’t work with Squid much so I don’t know all the details. The above is all I’ve come to know.

    Reply

    • Forgot to be more specific in original post. For X-Cache MISS, I meant it is not in server’s cache at time of request being made, but on next request, it should be a HIT since it is being cached with the current request. And I meant you clear X-Cache-Lookup only at the server side and not from any HTTP request headers unlike X-Cache which can be cleared on a per request level via “Pragma: no-cache” request header.

      Reply

      • Basically X-Cache tells you if the page you’re viewing was a cache-copy from one proxy cache level (if you happens to pass through different levels of cache). X-Cache-Lookup it’s like your browser is saying “I COULD have used that cache copy from that proxy (lookup hit) but right now I’m not using it (x-cache miss) or rather yes, i’m using it (x-cache hit).

        The thing that complicates everything is your local browser cache, because there’s no header explicitly saying that you’re using a cache

      • In response to your (Vide’s) comment about local browser cache complicating matters here, I guess it gets further complicated when you consider the browser endpoint could be another HTTP client (e.g. in code like Java/Python/etc., or some REST client tool, or test tools like JMeter, SOAPUI, etc.). Because those clients may or may not have a “local” (browser) cache that caches data locally itself.

        So from your explanation, for a single proxy server, what can be interpreted from

        X-Cache MISS with X-Cache-Lookup HIT?
        X-Cache MISS with X-Cache-Lookup MISS?
        X-Cache HIT with X-Cache-Lookup HIT?

        and will there ever be a case of

        X-Cache HIT with X-Cache-Lookup MISS? I don’t think so?

Leave a comment