ETag to the rescue

    It's no secret that the HTTP protocol, or rather, in that part of it that is the response from the server, has such wonderful headers as Last-Modified and ETag (You can read more in the protocol specification ). They are urged to speed up the process of receiving content from the server, or rather to save the client from downloading data that has not been changed since the previous request.

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

    But all this was until yesterday, when I got into a situation where Last-Modified could not cope. And this situation is quite common - multilingual content. In my case, the identifier of the current language is stored in a session on the server and the URL for different languages ​​is the same, which led, in fact, to the problem. Having started work on optimizing the site, 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 modification of the content. In this case, when changing the language, the client received different ETag for the same URL and accordingly reloaded the page again.

    As a conclusion, I would like to draw attention (and first of all) to the fact that you should not immediately ridicule and / or criticize colleagues in the shop if some things at first glance seem ridiculous or silly to us. Perhaps we ourselves do not notice something yet.

    Also popular now: