проблема в том, что с помощю программы HttpWatch видно что все рисунки и скрипты загружаються с кеша при переходах между страницами. Експеримент подтверждается тем, что когда я вножу изминения в джава-скрипт файл или удаляю рисунок на сервере, то все работает как прежде. помогает только Ф5.
Вопрос: как заставить браузер обновлять скрипты и рисунки при переходах между страницами, тоесть совсем не кешировать данные. Спасибо.
Здравствуйте, 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], Екатеринбург.
спасибо за детальые обяснения.... очень помогло....
проблема в следующая (с чего все началось):
надо при нажитии клавиши Back редиректить браузер на предефайнутую траницу. Я придумал следующий алгоритм:
1. на клиенте делаю <input type='hidden' value='0'>
Сабмит происходит на всех страницах с помощю одной функции. При сабмите значение хидн елемента инкрементируется на 1.
2. на сервере мы проверяем, если значение хидн елемента больше 1 то редиретим на предефайнетею страницу.
теперь допустим юзер нажал кнопку Back. Переходим на страницу назад, при етом как я понимаю страница вытаскивается с кеша. Значение хидн елемента там 1. При сабмите страницы на сервер оно инкрементируется на 1, и принимает значение 2. На сервере проесзодит проверка 2>1, и соответственно редирект. Проблема заключается в том что если юзер нажал кнопку Back а потом F5, то значение хидн елемента обнуляется, и страницу можна свободно сабмитить.
Вот.
только-что ище нашел одно решение — на онлоад страницы проверять, если значение хидн переменной =1, то с помощю скрипта редиректить на определенную страницу.
Буду очень признателен если оставите свои коментарии.
Заранее спасибо.
ICQ: 3066512
... << RSDN@Home 1.1.3 stable >>
Re[3]: как отключить кеш
От:
Аноним
Дата:
27.01.05 12:11
Оценка:
Здравствуйте, sv.vlad, Вы писали:
SV>спасибо за детальые обяснения.... очень помогло.... SV>проблема в следующая (с чего все началось): SV>надо при нажитии клавиши Back редиректить браузер на предефайнутую траницу. Я придумал следующий алгоритм: SV>1. на клиенте делаю <input type='hidden' value='0'> SV> Сабмит происходит на всех страницах с помощю одной функции. При сабмите значение хидн елемента инкрементируется на 1. SV>2. на сервере мы проверяем, если значение хидн елемента больше 1 то редиретим на предефайнетею страницу.
SV>теперь допустим юзер нажал кнопку Back. Переходим на страницу назад, при етом как я понимаю страница вытаскивается с кеша. Значение хидн елемента там 1. При сабмите страницы на сервер оно инкрементируется на 1, и принимает значение 2. На сервере проесзодит проверка 2>1, и соответственно редирект. Проблема заключается в том что если юзер нажал кнопку Back а потом F5, то значение хидн елемента обнуляется, и страницу можна свободно сабмитить.
Кажется я примерно догадываюсь о чем идет речь, ты делаешь что-то вроде оформления заказа или регистрации, состоящей из нескольких шагов, причем логика перехода между шагами определяется ответами на предыдущих шагах. И нужно чтобы пользователь последовательно выполнил все шаги, ничего не пропуская и не бегая взад-вперед. Угадал?
Все что тебе нужно сделать — это использовать механизм сессий, надеюсь ты знаком с ними. В сессии ты просто хранишь номер текущего шага. Допустим, в самом начале $_SESSION['step'] = 0;, при сабмите некой формы, например, с кнопкной [Начать], в обработчике этой формы ты делаешь $_SESSION['step'] = 1; Если у тебя происходит редирект после пост-запроса (что весьма желательно), на страницу к примеру: /order.php?step=1, то на этой странице делаешь проверку:
session_start();
....
if (isset($_GET['step']) && isset($_SESSION['step']) && $_GET['step'] == $_SESSION['step'])
{
// все хорошо, выводим страницу с формой
}
else
{
header('Location: '.$full_url_here_to_first_step);
exit();
}
Дело в том что на .NET написан специальный Web фреймворк и чистый ASP.NET практически не используется, поетому передача и контролирование GET параметров
немного проблематично. Преимущество надается использованию POST параметров.
Здравствуйте, sv.vlad, Вы писали:
SV>Здравствуйте, <Аноним>, Вы писали:
SV>[...skiped...]
SV>Дело в том что на .NET написан специальный Web фреймворк и чистый ASP.NET практически не используется, поетому передача и контролирование GET параметров SV>немного проблематично. Преимущество надается использованию POST параметров.
Сессия — это не ГЕТ параметр. В ПХП (обычно) — это файлик с массивом данных, который храниться на сервере и взаимно однозначно отвечает сессии браузера (по кукам или по ГЕТ/ПОСТ параметру).
Здравствуйте, King Oleg, Вы писали:
KO>Здравствуйте, sv.vlad, Вы писали:
SV>>Здравствуйте, <Аноним>, Вы писали:
SV>>[...skiped...]
SV>>Дело в том что на .NET написан специальный Web фреймворк и чистый ASP.NET практически не используется, поетому передача и контролирование GET параметров SV>>немного проблематично. Преимущество надается использованию POST параметров. KO>Сессия — это не ГЕТ параметр. В ПХП (обычно) — это файлик с массивом данных, который храниться на сервере и взаимно однозначно отвечает сессии браузера (по кукам или по ГЕТ/ПОСТ параметру).
[ ... Если у тебя происходит редирект после пост-запроса (что весьма желательно), на страницу к примеру: /order.php?step=1, то на этой странице делаешь проверку: .... ]
спасибо, я в курсе что такое сессия. Я не могу сделать передачу параметра с GET запросом при редиректе на страницу. Фреймворк не позволяет.
Здравствуйте, sv.vlad, Вы писали:
SV>спасибо, я в курсе что такое сессия. Я не могу сделать передачу параметра с GET запросом при редиректе на страницу. Фреймворк не позволяет.
Во-первых, странный фрейморк.
Во-вторых, к делу это не относиться. Можешь и ПОСТ запросы правильно обрабатывать.
KO>Во-первых, странный фрейморк.
не такой уж и странный. KO>Во-вторых, к делу это не относиться. Можешь и ПОСТ запросы правильно обрабатывать.
я так и делаю. возникли пробемы при нажимании кнопки Ф5, когда контент хидн переменной, которая сабмитится на сервер, заново инициализ. старым значением. (которое сохраняется на сервере)
Здравствуйте, sv.vlad, Вы писали:
KO>>Во-вторых, к делу это не относиться. Можешь и ПОСТ запросы правильно обрабатывать. SV> я так и делаю. возникли пробемы при нажимании кнопки Ф5, когда контент хидн переменной, которая сабмитится на сервер, заново инициализ. старым значением. (которое сохраняется на сервере)
У тебя там JavaScript присутствует, который изменяет значение инпута?
И вообще, запросы с ПОСТ не должны кешироваться. Никем и никогда.
Здравствуйте, King Oleg, Вы писали:
KO>Здравствуйте, sv.vlad, Вы писали:
KO>>>Во-вторых, к делу это не относиться. Можешь и ПОСТ запросы правильно обрабатывать. SV>> я так и делаю. возникли пробемы при нажимании кнопки Ф5, когда контент хидн переменной, которая сабмитится на сервер, заново инициализ. старым значением. (которое сохраняется на сервере) KO>У тебя там JavaScript присутствует, который изменяет значение инпута?
присутствует KO>И вообще, запросы с ПОСТ не должны кешироваться. Никем и никогда.
ето мне еще предстоит доследить. Еще тогда один вапрос: при нажатии на Ф5 данные сабмитяться на сервер или нет?
А как будет в такой ситуации: на странице А при сабмите я инкрементнул значение хидн переменной. Перешел на страницу В. Со страницы В я нажал на клавишу БЕК в браузере. Какое будет значение переменной?
KO>>У тебя там JavaScript присутствует, который изменяет значение инпута? SV> присутствует
В этом может быть проблема. Известно, что некоторые браузеры повторяют выполнение JS (или просто сохраняют в кеш уже измененную с помощью JS страницу и выводят именно ее) после F5. SV>Еще тогда один вапрос: при нажатии на Ф5 данные сабмитяться на сервер или нет? SV> А как будет в такой ситуации: на странице А при сабмите я инкрементнул значение хидн переменной. Перешел на страницу В. Со страницы В я нажал на клавишу БЕК в браузере. Какое будет значение переменной?
У меня что ИЕ, что ФФ спрашивает разрешение отослать ПОСТ запрос при нажатии "назад" или "вперед" для отображения страницы, для формирования которой использовался данный метожд запроса.
Другими словами, автоматичеки браузеры вообще не должны отправлять запрос на сервер. Должны спросить пользователя. Хотя нет, не должны, но ИЕ точно это делает.
П.С, Красиво закрутил?
