Hi, I am Sanjeet Tiwari...
Let's talk about

Back to Notes

HTTP Caching

Web

The way it works is a cache is placed at client side (browser), proxy server or the reverse proxy server, which can be used to achieve lower response times. Overall load and bandwidth utilization at the server can hugely improve with the use of caches.

Whenever a client requests a resource, it first goes to the cache.

Some HTTP headers have been formulated to determine how the caching for a resource will be done -

We have some pre-HTTP1.1 cache headers which are still supported, but are not being used -

  1. Expires - It contains the absolute time of the moment, the resource will be termed stale or expired.
  2. Pragma - It can contain only one value - no-cache, which is used when certain resource shouldn’t be cached.

In HTTP1.1, we got a new header - cache-control which comes along with many directives -

  1. private - It means that the content can be cached only at the client side (browser).
  2. public - It means that the content can be cached at public locations, mainly the proxies.
  3. max-age - It conveys the maximum number of seconds a content can be kept in a cache.
  4. no-store - It means that the content can not be stored in a cache.
  5. no-cache - It means that the content can be cached but in order for client to reuse it, the client must validate itself mostly via Etag directive.

In the event, we get value like cache-control: max-age=3600, public, it means that the content can be cached at public places for maximum of 3600 seconds.

In the event, we get value like cache-control: max-age=3600, private, it means that the content can be cached at the client side only for maximum of 3600 seconds.

  1. s-max-age - ‘s’ stands for shared. In a situation wherein we see a header like - cache-control: max-age:600, s-max-age:3600, it would mean the content can stay for 600 seconds on the client, and for 3600 seconds on the shared public spaces.
  2. must-revalidate - Sometimes, whenever there is any network issue, or the server is down, the client can serve you the stale data if when max-age has expired. To override it, we specify must-revalidate which specifies that the client should not serve the stale content and must get the good content from the server.
  3. proxy-revalidate - It’s the same behavior as must-revalidate but with proxies. But here in this case, the client can serve the stale content to the user, but if it reaches a proxy, they can’t serve stale content to the client.

Directives can be mixed like this - Cache-control: max-age=300, s-max-age=3600, public, must-revalidate.

Cache Validation

Etag and If-None-Match

ETag is usually used by the server to send along a unique identifier for the resource which was sent to the client. Lets say if server had responded with an image, and these headers -

Cache-control: max-age=3600, public;
Etag: "2uh878fbghfd89fvfd";

& lets consider if client sends back another header - If-None-Match, and passes along same Etag in the header like - If-None-Match: "2uh878fbghfd89fvfd", it would mean

We can have weak Etags as well, which are prefixed by a W, which necessarily means that 2 resources with same Etag might not be fully same.

Last-Modified and If-Modified-Since

Last-Modified header contains the timestamp of the moment the resource was last modified. The logic is same as that of Etag.

Video Source

Everything you need to know about HTTP Caching

Everything you need to know about HTTP Caching

the roadmap

Last updated on 22-07-2024