ETag to the rescue

It is not a secret for anyone that in the HTTP protocol, and more precisely in its part that is a response from the server, there are such remarkable headers as Last-Modified and ETag (for more details, see the protocol specification ). They are designed to speed up the process of obtaining content from the server, or rather to save the client from loading data that has not been changed since the previous request.

So here. For me, the fact of the existence of two, essentially identical, mechanisms to inform the client whether the content of the page has changed or not has been a little alarming. Little. More precisely, I did not understand what ETag is for, if I always had one Last-Modified and user case for another I couldn’t even imagine (although I wondered honestly, I didn’t really care).

But that was all until yesterday, when I got into a situation where Last-Modified failed. And this situation is quite common - multilingual content. In my case, the identifier of the current language is stored in the session on the server and the URL for different languages ​​is the same, which led, in fact, to the problem. Having started the work on site optimization, I turned on conditional caching and found that the language switch stopped working.

This is where ETag came in handy, instead of the usual Last-Modified. And I began to build it very plainly - namely, the concatenation of the current language and the date of the content modification. In this case, when changing the language, the client received different ETag for the same URL and accordingly reloaded the page again.
')
And as a conclusion, I would like to draw attention (and first of all) to the fact that you should not immediately make fun and / or criticize colleagues in the shop, if some things at first glance seem ridiculous or stupid to us. Perhaps we ourselves do not notice anything yet.