Последний вариант, кстати, использует ВКонтакте. А для того, чтобы страница пользователя оставалась всегда актуальной, вне зависимости от настроек кеша, там к URL добавляется рандомное 4-х значное число.
> А для того, чтобы страница пользователя оставалась всегда актуальной, вне зависимости
> от настроек кеша, там к URL добавляется рандомное 4-х значное число.
А они что, не слышали про Cache-Control? С рандомными числами в качестве «уникализатора» не все здорово, на самом деле.
Практически все браузеры (ручаюсь за FF2-3 и IE7-8) отлично все кэшируют, если им правильно сказать как они должны это делать. Например,
Cache-Control: «public, must-revalidate» (говорит о том, что можно кэшировать, но при этом надо валидировать)
Expires: -1 (говорит о том что ресурс устарел и его надо проверить, но не всем браузерам это обязательно говорить)
Last-Modified: дата (на основании этого сервер шлет либо 200 OK, либо 304 Not Modified)
Кроме того, если использовать строгий валидатор ETag, то его одного уже будет достаточно, чтобы все работало без всяких лишних инструкций/заголовков в response.
Рандомные числа — это что-то вроде «хака». Но честно говоря, разобраться в RFC 2616 сложнее, чем быстренько все имплементировать с помощью этого простого «хака».
Спасибо, хорошая книжка. Однако наличие хорошей книжки по предмету на гарантирует, что все ее обязательно прочтут. В комментах к статье по меньшей мере двое отметили, что возьмут описанный здесь способ на вооружение.
Способ, действительно, очень хороший, поскольку избавляет от необходимости править шаблон страницы, и, кстати, упоминается в конце статьи, но не надо забывать, что не у всех есть возможность или умения, чтобы закодировать эту логику на серверной стороне.
Спасибо за положительную оценку, а что касается бесполезного текста, то ведь не все в равной степени владеют материалом: кому-то именно «бесполезный» текст поможет понять логику изложения.
Просто часто материалы просматриваются по диагонали и лишние лирические отступления просто мешают оперативному восприятию информации.
Спасибо за статью и поднятую тему.
> Вы запускаете FTP-клиента, перетаскиваете gif-ки и css-ки с левой панели на правую и, весь такой довольный, открываете вебсайт в своем любимом браузере…
бардак начался уже здесь, нужно было воспользоваться svn или другим механизмом, который поддерживает целостность версии.
может я ошибаюсь, но браузеры (все) вообще не должны кешировать что-либо с переменными в get запросе, независимо от заголовков сервера.
так что такой способ можно использовать если нужно просто и навсегда избавится от кеширования чегото )
а для обновления статики проще всего сделать реврайт урлов типа /(\w+)_\d+\.(\w+) -> /$1.$2
тем самым подсовывая пользователям, когда необходимо, новое название файла (типа style_1.css, style_2.css для файла style.css), а сам файл переименовывать не надо.
Отсекать у людей с IE возможность закешировать данные не очень хорошо.
Лучше файл переименовывать. А еще лучше, чтобы он автоматически переименовывался. А еще лучше — организовать у себя нормальную системы сборки файлов, чтобы все нужные файлы собирались в 1, сжимались и переименовывались. В django для этого есть django-compress, например.
Самый лучший способ, это использовать рандомное число не в query string а в имени файла, и использовать mod_rewrite.
В частности можно:
./cache/1234567/style.css — старый
./cache/1111111/style.css — новый
а реально эти файлы должны ссылаться на один. Как говорил выше, добиться этого можно с помощью mod_rewrite
Вебные хитрости: Принудительный рефреш статики