Refer: http://thespringthing.blogspot.com/2015/06/etags-and-browser-cache.html
ETags and browser cache
Caching resources on the browser is one of the patterns followed to minimize redundant trips to the server and thus reduce load on the server. This works well for data that is static. But, there are cases where the data changes every once in a while (although less frequently) and you would want the browser to get the latest data without waiting for the cached data to expire. e.g. changes to a css or javascript in the new version of the application should be reflected immediately on the browser. To handle these refreshes, you might be tempted to make it a non-cacheable resource. Entity tags( or ETags for short) help you cache such resources.
ETag is a unique identifier that represents the response content of a request. By comparing Etags, you should be able to tell if the response for a request has changed or not, and decide if you need to send the new data back to the client or just use the cached data.
HTTP supports ETag response headers which can be used along with If-None-Match request headers for managing cache data. These headers are meant to be used for GET and HEAD requests, which are the recommended methods for fetching cacheable resources.
The following sequence diagrams illustrates the ETag workflow for an example of 3-step resource fetch. Each step requests for the same resource.
Step 1
Browser sends a request for a resource
Server creates an ETag value for the resource using hash or other techniques.
Server sets this value in "ETag" header in response.
Server sends the resource along with ETag.
Client caches the resource and the ETag
Step 2
Client requests for the same resource
Client sends the ETag value for the resource through the If-None-Match header.
Server calculates the ETag for the resource.
Server compares the new ETag with If-None-Match.
If it matches, then server sends a 304 response code.
Client uses the data from cache.
Step 3
Client requests for the same resource.
Client sends the ETag value for the resource through the If-None-Match header.
Server calculates the ETag for the resource.
Server compares the new ETag with If-None-Match.
If it does not match, then server sets the ETag response header with the new value.
Server sends the resource along with ETag.
Client caches the new resource and the ETag
ETag generation
ETag generation in itself could add some amount of latency, depending upon the techniques used. The simplest technique to calculate is to generate a hash of the content through MD5 algorithm or something similar. This could be pretty sluggish depending upon the size of the content.
The ETag need not necessarily be unique, as long as it can indicate the change in the content. For example, in one of my projects I used the content version as the ETag. The version indicated change in the content and that was good enough for me to refresh the cache.
