Ни для кого не секрет, что в протоколе HTTP, а точнее в той его части, что является ответом с сервера, есть такие замечательные заголовки, как Last-Modified и ETag (Подробнее можно прочитать в
спецификации протокола). Призваны они ускорить процесс получения контента с сервера, а точнее избавить клиента от загрузки данных, которые не были изменены с момента предыдущего запроса.
Так вот. Для меня факт существования двух, по-сути одинаковых, механизмов сообщить клиенту изменилось ли содержимое страницы или нет немного настораживал. Немного. Точнее я его не понимал для чего нужен ETag, если мне всегда было достаточно одного Last-Modified и юзкейса для другого я даже и представить не мог (хотя меня этот вопрос, признаться честно, не особо и волновал).
Но это все было до вчерашнего дня, когда я попал в ситуацию, где Last-Modified не справился. И ситуация эта — достаточно распространенная — мультиязычный контент. В моем случае идентификатор текущего языка хранится в сессии на сервере и URL для разных языков один и тот же, что и привело, собственно, к проблеме. Начав работы по оптимизации сайта я включил условное кеширование и обнаружил, что переключатель языка перестал работать.
Вот тут-то мне и пригодился ETag вместо привычного Last-Modified. Причем строить я стал его очень незамысловато — а именно конкатенацией текущего языка и даты модификации контента. В этом случае при смене языка клиент получал для одного и того же URL различные ETag и соответственно перегружал страницу заново.
А в качестве заключения мне хотелось бы обратить внимание (и своё в превую очередь) на то, что не стоит сразу высмеивать и/или критиковать коллег по цеху, если некоторе вещи с первого взгляда кажутся нам нелепыми или глупыми. Возможно это мы сами пока что чего-то не замечаем.
комментарии (43)
а last-modified — соответственно http1.0, оставленное для обратной совместимости
В любом случае, мне кажется это не самое подходящее место для обсуждения этого вопроса.
К примеру, если в gmail будет отдельная ссылка на каждый язык интерфейса-- это уже выглядит победой теории над здравым смыслом.
Это не ради холивара; это просто к тому что не надо так категорично высказываться. У каждого правила есть своя область применимости
Следует также учитывать, что, как и с обычными веб-страницами, совпадение перечней веб-страниц у разных языковых версий веб-интерфейса не является гарантированным. С раздельными URL’ами никогда (даже теоретически) не возникнет проблемы, когда англоговорящий человек даёт ссылку русскоговорящему, и тот попадает на страницу 404.
www.mydigitallife.info/2009/01/11/free-unlimited-activation-product-key-to-activate-windows-7-beta/ru/
С ETag'ами, кстати, проблемы разные есть еще. Например, с ними gzip не работает иногда. YSlow за ETag'и даже баллы снимает.
issues.apache.org/bugzilla/show_bug.cgi?id=39727
nginx последних версий, кстати, лишен этого бага
Т.е. проблема, конечно, есть, но при наличии прямых рук она на указанном окружении обходится (либо ее решение лежит уже за пределами данного окружения).
Поэтому многие рекомендуют отключать ETag на крупных проектах.
FileETag -INode
Да и суть тэгов не в том, чтобы их просто посылать, а посылать правильные значения :)
последний абзац вы именно на этот случай написали?:-)
www.xml.com/pub/a/2006/02/01/doing-http-caching-right-introducing-httplib2.html
Ну и в Сагалаева тоже есть на русском.