HTTP Caching

Recently, I had to design static resource Caching to be able to optimize Network traffic and User experience on Client devices. The requirement was that Client should use Cache for a given picture, if it is unchanged at the Server. Request the fresh copy of picture, if changed.

As our requests are  HTTP REST API calls, we turned to it. HTTP gives multiple ways to control cache. I have explained them following, and why it didn't work for our case.

instructs client to not cache the resource / response. This, of course, will not work, as Device should not request it from Server, if Available with Device and Unchanged in Server.

instructs client to not store the resource / response. This will not work for the same reason, as no-cache.

instructs client to invalidate the resource / response, after number of seconds elapsed in max-age. This will not work too, as we cannot predict the changes to resource.

sent by the Client / Device to query for Modification status. If Modified, send the new copy of resource, or else the local copy will be used. While this works better and satisfy requirement, a round-trip to the Server is still needed,  before local copy can be used. Also, there has to be handling done on Server side (as resource is not a static file, but a Database object).

sent by Server to indicate Modification time of the resource. This, like If-Modified-Since, works well and satisfy requirement, the Client Device still need to handle the response, do the math (Local resource time & Server resource time) to download the resource.

With above, it was clear that an out of the box HTTP header solution will not work. Hence, I devised another solution, where once Server knows about a changed state of a resource, will change the resource URL. To make it easier, the Server was already storing modification timestamp. We made it part of resource name.

Hence, the resulting URL now is modified each time a resource is modified. URL remains same, otherwise. On URL change, Client cache already by design request fresh copy of resource (it is treated a different resource due to change in URL).

Hope it helps someone. Happy Caching!!

Ref. 1

Ref. 2


Popular posts from this blog

AWS RDS incompatible-parameters solved

504 Gateway Timeout on Amazon AWS ELB (Elastic Load Balancer)