Здравствуйте, sv.vlad, Вы писали:
SV>есть такой кусок кода в каждой странице
SV><HEAD>
SV> <meta http-equiv="Cache-Control" Content="no-cache, must-revalidate">
SV> <meta http-equiv="Pragma" Content="no-cache">
SV> <meta http-equiv="Expires" Content="0">
SV>проблема в том, что с помощю программы HttpWatch видно что все рисунки и скрипты загружаються с кеша при переходах между страницами. Експеримент подтверждается тем, что когда я вножу изминения в джава-скрипт файл или удаляю рисунок на сервере, то все работает как прежде. помогает только Ф5.
SV>Вопрос: как заставить браузер обновлять скрипты и рисунки при переходах между страницами, тоесть совсем не кешировать данные. Спасибо.
1. Прежде всего, хочу заметить, что указывая в meta эквивалент HTTP-заголовка ответа ты пытаешься управлять параметрами кэширования конкретно этой страницы, то есть текста, и эти параметры не имеют никакого отношения к картинкам, которые вставлены в HTML-код, т.к. для их загрузки производятся отдельные HTTP-запросы.
2. Параметры, указанные в meta http-equiv имеют меньший приоритет по сравнению с настоящими заголовками ответа сервера, которые есть, но ты их не видишь в браузере. Так что если веб-сервер посылает другие значения этих заголовков, то твои не будут иметь силы. (проверено опытами во всех основных браузерах)
3. В идеале, запрашивая некий URL, сервер возвращает HTTP-заголовок "Last-Modified" с датой и временем его последней модификации в формате GMT и эта дата и время сохраняется в кэше браузера вместе с телом ответа браузера (страницей, картинкой и пр.) При запросе некоего URL браузер, если у него включен кэш, сначала проверяет нет ли у него в кэше этого URL и если есть, то посылает на сервер запрос с дополнительным заголовком "If-Modified-Since:", в котором в качестве значения передает ту самую дату и то самое время последней модификации запрашиваемого контента. Веб сервер анализирует этот заголовок и если актуальная дата и время модификации контента на сервере совпадает с датой, переданной в заголовке "If-Modified-Since", то сервер возвращает код ответа HTTP/1.1 304 Not Modified и пустым телом ответа. Такого рода ответ сообщает браузеру о том, что контент по запрашиваемому URL не изменился и его можно смело взять из кэша, не скачивая снова. Это возможность ускорить процесс повторной загрузки и отображения информации и сэкономить сетевой трафик.
4. Однако, это справедливо в основном лишь для статического контента (обычных файлов, лежащих внутри директории веб-сайта), а почти все современные сайты сделаны с применением серверных скриптов (PHP, ASP[.net], Perl и др.). Серверные скрипты генерируют нужный контент по запросу, то есть способны в произвольный момент времени при всех прочих равных условиях выдавать различный контент. Серверные скрипты по умолчанию вообще не возвращают браузеру заголовок Last-Modified (если разработчики об этом сами не позаботились, но именно так и бывает в 99.9%), таким образом контент генерируемый серверным скриптом практически не кэшируется и при повторном обращении скачивается целиком заново независимо от того изменился ли он реально или нет.
5. На практике дело обстоит так, что разные браузеры имеют различное поведение и в некоторых ситуациях даже не проверяют факт изменения контента запрашиваемого URL на сервере, а сразу берут из кэша. Это еще больше ускоряет процесс отображения страницы и еще больше уменьшает трафик, но приводит к тому, что в браузере иногда отображается устаревший контент. Больше всего этим грешит браузер Opera — он пытается брать из кэша все, что только может брать, если у хранимого в кэше контента не вышел срок годности, который задается настройками. Главным образом поэтому Opera считается самым быстрым браузером, но вот такой вот ценой.
Пожалуй, единственный способ гарантированно получить новый контент -- не допускать ситуации, когда запрашиваемый контент находится в кэше браузера, то есть менять URL, всякий раз добавляя к нему какие-нибудь незначащие ничего параметры случайным образом. Например, для браузера URL "
http://domain.com/1.jpg" и "
http://domain.com/1.jpg?rand=53146" — совершенно разные URL, хотя для сервера в общем случае — это один и тот же контент.
Однако, применение такого способа — это очень крайняя мера, и прежде чем на нее пойти необходимо несколько раз подумать: "А нет ли другого способа?", т.к. подобная система адресации на сайте может ввести в ступор и даже зацикливание сетевого паука (поискового робота), к тому же, пользователи хотели бы чтобы кэшировалось как можно больше, так что если есть такая возможность, нужно следовать правилу: "один url" = "один контент", и стараться избегать ситуаций когда "несколько url" = "один контент", а ситуаций "один url" = "много контентов" разруливать стандартными механизмами с применением Last-Modified, If-Modified-Since и возвратом кода результата запроса 304.
Если бы ты более конкретно привел описание свое задачи и показал пример, демонстрирующей проблему, то, вероятно, люди, обитающие здесь, смогли бы подсказать тебе более правильное решение.
-- С уважением, Павел Янченко.
Web-Студия JetStyle[.ru], Екатеринбург.
