5

I think that HTTP's ETag is exactly the mechanism for invalidating stale cached content. And digests are used for the same sake. Why are they better and why etags are not enough?

Konstantin Tikhonov
  • 309
  • 3
  • 14

1 Answers1

4

Because ETags still require the client to hit the server to see if the client's cached copy is still fresh. Rails puts a far future expires header on assets which means that the client will never hit the server again for an asset, it already has cached. Digests then become the means for the server to make a client get a new version of the asset. I think Rails used to use timestamps instead of digests, but digests have the added, small benefit that if you revert the asset back to its previous state, its digest will be the same, and the client may still have it cached.

KaptajnKold
  • 10,638
  • 10
  • 41
  • 56
  • 2
    Digests also have the benefit (over timestamps) that a new deployment might end up in asset files all having different timestamps when they've actually all got the same content. In that case, a timestamp approach would lead to redownloading the (identical) asserts, but the digest approach ensures the cache is still valid – Gareth Sep 27 '16 at 13:40