код на этой странице запрещает кэширование вперед и назад
Не кэшировать!
Современные браузеры достаточно часто используют в своей работе локальный кэш. Что это означает? Это означает что браузер, получив от сервера html-документ, картинку или другой ресурс, размещает его в своем локальном кэше (проще говоря, записывает полученный ресурс на жесткий диск машины пользователя) и при последующих запросах к такому ресурсу не обращается на сервер, а получает ресурс из локального кеша.
Данная алгоритм работы браузеров резко повышает скорость загрузки html-документов. Так как если ресурс уже загружался, и как следствие расположен в локальном кэше, то время доступа определяется не пропускной способностью канала связи (например, модемного подключения) а скоростью работы жесткого диска.
Однако наряду с достоинствами данный метод так же порождает ряд проблем. В частности большинство начинающих web-программистов, при разработке динамических сайтов, сталкивается с одной и той же проблемой. Суть этой проблемы заключается в том, что вместо повторного обращения на сервер за страницей, запускающей на сервере скрипт, модифицирующий некую информацию, браузер обращается в локальный кэш. И в результате, например трех обращений, происходит не три модификации информации, расположенной на сервере, а только одна.
Для того, что бы заставить браузер каждый раз обращаться за страницей на сервер необходимо запретить браузеру заносить данный ресурс в кэш. Ниже приведены наиболее распространенные методы, запрещающие кэширование или позволяющие его обойти.
Генерация нового URL
Допустим что запрашиваемый ресурс имеет следующий url: test.html?id=7. Как видно из url’а ему передается один параметр. Добавим, например, при помощи JavaScript, в url еще один параметр, а его значением сделаем случайное число. В результате url будет выглядеть следующим образом: test.html?id=7&rnd=0.6700820127538827. Случайный параметр будет каждый раз генерироваться заново. Ниже приводится листинг, демонстрирующий этот подход:
Каждый раз результат такого запроса будет кэшироваться, но так как кэширование производится по всему url, то каждый раз будет получаться новый url и браузер будет вынужден запрашивать с сервера ресурс, так как url двух запросов не будут совпадать в точности.
Поля заголовков
Управлять кэшированием можно так же со стороны сервера. Для этого ресурс, отправляемый браузеру, сопровождается полями заголовка. Детальное описание полей заголовка может быть найдено в стандарте Rfc 2068, который описывает протокол HTTP 1.1.
Поле заголовка Expires
Значением данного заголовка является дата, после которой содержимое ресурса устареет. Если пользователь после этой даты обратиться к ресурсу, браузер должен запросить ресурс у сервера, а не из локального кэша.
WordPress.org
Вечер добрый.
В Интернет Эксплорере вижу поля плагина независимо от выбранного способа доставки.
При нажатии поля области ничего не происходит, даже если выбран нужный способ доставки.
При этом в Хроме все нормально работает.
Скрин: http://i.piccy.info/i9/27869a2e42b623a37ee0ef07b42fbb07/1571331740/74405/1342955/Bez_ymeny_1.jpg
Это у меня на сайте ошибка или в плагине?
The page I need help with: [log in to see the link]
Информация из лога ошибок:
[Thu Oct 17 20:06:06 2019] [warn] [client ***] mod_fcgid: stderr: get_option, referer: https://kotyara.com.ua/checkout/
[Thu Oct 17 20:06:06 2019] [warn] [client 95.67.106.210] mod_fcgid: stderr: PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, class ‘kirillbdev\\WCUkrShipping\\Classes\\CheckoutValidator’ does not have a method ‘afterCheckoutValidation’ in /home/hhlarEi3B7aW/kotyara.hostenko.com/wp-includes/class-wp-hook.php on line 286, referer: https://kotyara.com.ua/checkout/
Консоль ИЕ при загрузке ошибки выдает это:
DOM7011: Код на этой странице запрещает кэширование вперед и назад. Дополнительные сведения см. по адресу http://go.microsoft.com/fwlink/?LinkID=291337
Файл: checkout
HTML1300: Произошел переход.
Файл: checkout
HTML1509: Несопоставленный закрывающий тег.
Файл: checkout, строка: 450, столбец: 1
SCRIPT1014: Недопустимый знак
Файл: nova-poshta-checkout.js, строка: 31, столбец: 21
При переходе по ссылке последней строки попадает на:
html += ;
Место расположения курсора: на первом знаке `
@kotyarashop Спасибо за обнаруженную проблему. Ближе к ночи выпущу фикс.
Предотвращение кэшинга в Internet Explorer
Настольное приложение Internet Explorer 11 будет снято с службы поддержки 15 июня 2022 г. (список того, что имеется в области, см. в faq). Те же приложения и сайты IE11, которые вы используете сегодня, могут открываться в Microsoft Edge режиме Internet Explorer. Подробнее см. здесь.
В этой статье описывается использование http-загонщиков для управления кэшингом веб-страниц в Internet Explorer.
Оригинальная версия продукта: Internet Explorer
Исходный номер КБ: 234067
Сводка
С помощью Microsoft Internet Information Server (IIS) можно легко отметить высокостабильную или чувствительную страницу с помощью следующего сценария в крайнем начале определенных страниц ASP (ASP):
Истечение срока действия и заглавная дата истечения срока действия
Настоятельно рекомендуется, чтобы все веб-серверы использовали схему для истечения срока действия всех веб-страниц. Это плохая практика для веб-сервера, чтобы не поставлять информацию о сроках действия через http expires ответ загона для каждого ресурса, возвращаемой к запрашивающих клиентов. Большинство браузеров и промежуточных прокси сегодня уважают эту информацию о сроках действия и используют ее для повышения эффективности коммуникаций по сети.
Всегда используйте заглавную папку Expires, чтобы указать наиболее разумное время, когда определенный файл на сервере должен быть обновлен клиентом. При регулярном обновлении страниц наиболее эффективным является следующий период обновления. Возьмем, например, ежедневную страницу новостей в Интернете, которая обновляется каждый день в 5 утра. Веб-сервер для этой страницы новостей должен возвращать заготвка Expires со значением для 5 утра. на следующий день. После этого браузеру не нужно снова связываться с веб-сервером, пока страница не изменится.
Страницы, которые не должны изменяться, должны быть помечены со сроком действия около одного года.
Во многих случаях веб-серверы имеют одну или несколько волатильных страниц на сервере, которые содержат сведения, которые подлежат немедленному изменению. Эти страницы должны быть помечены сервером со значением «-1» для загона Expires. В случае будущих запросов пользователя Internet Explorer обычно обращается к веб-серверу для обновления этой страницы с помощью условного запроса If-Modified-Since. Однако страница остается в кэше диска (Временные файлы Интернета). И страница используется в соответствующих ситуациях без контакта с удаленным веб-сервером, например:
Заглавная Cache-Control
Однако некоторые страницы настолько неустойчивы или чувствительны, что не требуют кэшинга дисков. С этой целью Internet Explorer поддерживает http 1.1 Cache-Control. Этот загон предотвращает все кэшы определенного веб-ресурса, если значение без кэша задано сервером HTTP 1.1.
Загон Pragma: No-Cache
К сожалению, устаревшие серверы HTTP 1.0 не могут использовать Cache-Control. Для обратной совместимости с серверами HTTP 1.0 Internet Explorer поддерживает специальное использование загона HTTP Pragma: без кэша. Если клиент взаимодействует с сервером по безопасному подключению () и сервер возвращает загон Pragma: нет кэша с ответом, Internet Explorer не кэшировать https:// ответ.
Однако загон Pragma: no-cache не был предназначен для этой цели. Согласно спецификациям HTTP 1.0 и 1.1, этот заготок определяется только в контексте запроса, а не в ответе. Она предназначена для прокси-серверов, которые могут препятствовать достижению определенных важных запросов до конечного веб-сервера. Для будущих приложений Cache-Control является подходящим средством для управления кэшингом.
ТЕГИ HTTP-EQUIV META
Cache-Control ТЕГИ META HTTP-EQUIV игнорируются и не влияют на версии Internet Explorer 4 или 5. Чтобы использовать Cache-Control, этот заготчик должен быть указан с помощью http-заготчиков, как описано в разделе Cache-Control выше.
Использование стандартных http-заглавных заглавных команд предпочтительнее тегов META. Теги META обычно должны отображаться в верхней части РАЗДЕЛА HTML HEAD. И есть по крайней мере одна известная проблема с тегом МЕТА Pragma HTTP-EQUIV.
Параметры сервера для кэшинга
Если Cache-Control для использования на страницах, не включаемых в ASP, может потребоваться использовать параметры конфигурации сервера для автоматического добавления этого загона. В процессе добавления http-headers в ответы сервера для определенного каталога обратитесь к документу сервера. Например, в IIS 4 выполните следующие действия:
Не стоит использовать этот заготвщик глобально на всем веб-сервере. Ограничить его использование исключительно контентом, который абсолютно не должен быть кэшным для клиента.
Контрольный список проблем
Если вы применяли методы в этой статье и у вас по-прежнему возникают проблемы с кэшингом и internet Explorer, просмотрите этот удобный контрольный список шаг за шагом, прежде чем обращаться в Корпорацию Майкрософт за технической поддержкой:
Ссылки
Дополнительные сведения о HTTP/1.1 см. в странице RFC 2616.
Код на этой странице запрещает кэширование вперед и назад
За последние 60 дней ни разу не выходила
Сайт рассылки: http://4remind.ru
Открыта: 25-02-2012
Статистика
Как запретить кэширование страниц сайта
Не всегда и не для всех сайтов полезно кэширование всех или отдельных страниц. Некоторым это может показаться странным, ведь кэширование снижает нагрузку на сервер, особенно при большой активности и посещаемости посетителей, но только не тем, у кого на страницах сайтов или веб-сервисов слишком часто обновляется контент, а посетители при этом должны всегда получать самую свежую и актуальную информацию при каждой загрузке страниц. К таким веб-ресурсам можно отнести веб-чаты, голосования, игры, новости, счетчики и тому подобные. В этой статье будут представлены методы для запрета кэширования страниц сайта. 
Речь здесь не о том, как запретить кэш лишь в браузере, а о том, как запретить кэширование контента на стороне сервера. Многим наверно известны методы запрета кэширования в заголовках HTML-страниц, например упомянутые в Wikipedia, такие как
Кроме того можно использовать и такие
В первой строке указывается рекомендация запрещать кэширование вообще, а вторая строка указывает браузеру, что страница используется в приватном режиме, поэтому ее содержимое не должно кэшироваться. Мета-теги в третьей и четвертой строках указывают на то, что срок хранения в кэше ограничено временем max-age=10800 (что равно 3-м часам) для браузера и для прокси соответственно.
Приведенные выше в пример рекомендации хороши однако лишь для тех владельцев сайтов, у которых нет доступа к PHP-скриптам, и больше подходят для нединамических страниц. Это как, говорится, «последний шанс», и лишь потому, что многие браузеры, да к тому же их многочисленные версии, все меньше и меньше обращают внимание на то, что прописано в HEAD-секциях страниц сайтов. Каждый из них «тянет одеяло на себя» и не все и не всегда придерживаются каких-то стандартов. Другими словами, что что было сказано выше, может не сработать.
Запрет кэширования страниц на PHP
Вот пример простого указания сроков кэширования страниц сайта:
Однако на практике оказалось, что этого может быть недостаточно, и после многочисленных экспериментов с разными браузерами наиболее лучшим вариантом запрета кэширования на PHP будет такой подход:
В некоторых случаях может пригодиться в параметре заголовка использовать дополнительные параметры post-check=0 и pre-check=0
Некоторые добиваются запрета кэширования страниц или изображений методом добавления к ссылкам рандомного (случайного) числа, как параметра запроса. Точнее это не запрет, а попытка обмануть браузер, что мол он должен заново загрузить страницу, так как URL уже изменен:
Правда это не всегда и не на всех версиях и типах браузеров срабатывает, да и может помочь лишь в случаях, когда ссылки генерируются динамически.
Проверка, что кэширование отключено
Проверить, кэшируется ли страница или нет, можно с помощью добавления времени сервера, в которое была сгенерирована конкретная страница, непосредственно в код страницы. Это легко сделать с помощью PHP
Кроме того, Вы сможете указывать время ограничения кэширования, например:
Эти варианты директив имеют одинаковый смысл и значение, и будут ограничивать кэширование сроком на 1 месяц. Еще можно будет указывать типы файлов контента со сроком окончания времени кэширования или указанием времени их модификации:
На этом пожалуй пока все. Надеюсь информация будет для Вас полезной. Если же у Вас есть свои наработки, дополнения, то не стесняйтесь, пишите их в комментариях или шлите мне по почте, а я добавлю (после проверки) в эту статью.
Copyright © 2012-2013, 4remind.ru | Все права защищены | Постоянная ссылка
Хотите больше информации? Ознакомьтесь с другими материалами рубрики Утилиты, сервисы, серверы
Не прошло и недели с момента релиза WordPress 3.7, как вышла новая версия 3.7.1. Это всего лишь корректирующее обновление WordPress, в котором не было никаких изменений функциональности, кроме исправления 11 багов, трем из которых был выставлен высокий приоритет важности.
Подводные камни при использовании кэширования в nginx
В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.
В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.
Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*
Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.
Кэширование всей страницы целиком
Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).
Например, закэшировать главную страницу можно так:
Я не сильно преувеличу, если скажу, что каждая строчка в этом конфиге написана кровью. Здесь много подводных камней, давайте их все рассмотрим.
fastcgi_cache_path: простота отладки тоже важна
fastcgi_cache_path /var/cache/nginx levels= keys_zone=wholepage:50m;
В директиве fastcgi_cache_path я выставляю «пустое» значение для levels. Хотя это немного снижает производительность (файлы будут напрямую создаваться в /var/cache/nginx, без разбиения по директориям), но зато на порядок облегчает отладку и диагностику проблем с кэшем. Поверьте, вам еще не раз придется руками залезать в /var/cache/nginx и смотреть, что там хранится.
fastcgi_cache_valid: кэшируем код ответа 304 тоже
fastcgi_cache_valid 200 301 302 304 5m;
fastcgi_cache_key: внимательно работаем с зависимостями
fastcgi_hide_header: решаем проблемы с безопасностью
Директива fastcgi_hide_header очень важна. Без нее вы серьезно рискуете безопасностью: пользователи могут получить чужие сессии через сессионную Cookie в кэше. (Правда, в последних версиях nginx что-то было сделано в сторону автоматического учета данного фактора.) Понимаете, как это происходит? На сайт зашел Вася Пупкин, ему выдалась сессия и сессионная Cookie. Пусть кэш на тот момент оказался пустым, и в него записалась Васина Cookie. Затем пришел другой пользователь, получил ответ из кэша, а в нем — и Cookie Васи. А значит, и его сессию тоже.
Можно, конечно, сказать: давайте не будем вызывать session_start() на главной странице, тогда и с Cookies проблем не будет. В теории это так, но на практике данный способ очень неустойчив. Сессии часто стартуют «отложено», и достаточно какой-либо части кода «случайно» вызвать функцию, требующую доступа к сессии, как мы получим дыру в безопасности. А безопасность — такая штука, что если в той или иной методике может возникнуть дыра по неосторожности, то эта методика считается «дырявой» по определению. К тому же есть и другие Cookies, кроме сессионной; их тоже не надо записывать в кэш.
fastcgi_ignore_headers: не даем сайту «лечь» от нагрузки при опечатке
fastcgi_ignore_headers «Cache-Control» «Expires»;
Сервер nginx обращает внимание на заголовки Cache-Control, Expires и Pragma, которые выдает PHP. Если в них сказано, что страницу не нужно кэшировать (либо что она уже устарела), то nginx не записывает ее в кэш-файл. Это поведение, хотя и кажется логичным, на практике порождает массу сложностей. Поэтому мы его блокируем: благодаря fastcgi_ignore_headers в кэш-файлы попадет содержимое любой страницы, независимо от ее заголовков.
Кэширование с ротацией
Статическая главная страница — это не так уж и интересно. Что делать, если на сайте много материалов, а Главная выступает в роли своеобразной «витрины» для них? На такой «витрине» удобно отображать «случайные» материалы, чтобы разные пользователи видели разное (и даже один пользователь получал новый контент, перезагрузив страницу в браузере).
Вот кусочек конфига nginx, реализующий кэширование с ротацией:
Вы можете заметить, что по сравнению с предыдущим примером мне пришлось добавить еще 6 директив в location. Они все очень важные! Но не будем забегать вперед, рассмотрим все по порядку.
perl_set: зависимость-рандомизатор
С директивой perl_set все просто. Мы создаем переменную, при использовании которой nginx будет вызывать функцию встроенного в него Perl-интерпретатора. По словам автора nginx, это достаточно быстрая операция, так что мы не будем «экономить на спичках». Переменная принимает случайное значение от 0 до 9 в каждом из HTTP-запросов.
fastcgi_cache_key: зависимость от рандомизатора
Теперь мы замешиваем переменную-рандомизатор в ключ кэша. В итоге получается 10 разных кэшей на один и тот же URL, что нам и требовалось. Благодаря тому, что скрипт, вызываемый при кэш-промахе, выдает элементы главной страницы в случайном порядке, мы получаем 10 разновидностей главной страницы, каждая из которой «живет» 1 минуту (см. fastcgi_cache_valid).
add_header: принудительно выключаем браузерный кэш
Выше мы говорили, что nginx чувствителен к кэш-заголовкам, выдаваемым PHP-скриптом. Если PHP-скрипт возвращает заголовки «Pragma: no-cache» или «Cache-Control: no-store» (а также еще некоторые, например, «Cache-Control: не-сохранять, не-выдавать, меня-тут-не-было, я-этого-не-говорил, чья-это-шляпа»), то nginx не будет сохранять результат в кэш-файлах. Специально чтобы подавить такое его поведение, мы используем fastcgi_ignore_headers (см. выше).
Чем отличается «Pragma: no-cache» от «Cache-Control: no-cache»? Только тем, что Pragma — наследие HTTP/1.0 и сейчас поддерживается для совместимости со старыми браузерами. В HTTP/1.1 используется Cache-Control.
Однако есть еще кэш в браузере. И в некоторых случаях браузер может даже не пытаться делать запрос на сервер, чтобы отобразить страницу; вместо этого он достанет ее из собственного кэша. Т.к. у нас ротация, нам такое поведение неудобно: ведь каждый раз, заходя на страницу, пользователь должен видеть новые данные. (На самом деле, если вы все же хотите закэшировать какой-нибудь один вариант, то можно поэкспериментировать с заголовком Cache-Control.)
Директива add_header как раз и передает в браузер заголовок запрета кэширования. Ну а чтобы этот заголовок случайно не размножился, мы вначале убираем из HTTP-ответа то, что записал туда PHP-скрипт (и то, что записалось в nginx-кэш): директива fastcgi_hide_header. Ведь вы, когда пишете конфиг nginx-а, не знаете, что там надумает выводить PHP (а если используется session_start(), то он точно надумает). Вдруг он выставит свой собственный заголовок Cache-Control? Тогда их будет два: PHP-шный и добавленный нами через add_header.
expires и Last-Modified: гарантируем перезагрузку страницы
Есть и еще один повод выставлять Last-Modified вручную. Дело в том, что PHP-функция session_start() принудительно выдает заголовок Last-Modified, но указывает в нем… время изменения PHP-файла, который первый получил управление. Следовательно, если у вас на сайте все запросы идут на один и тот же скрипт (Front Controller), то ваша Last-Modified будет почти всегда равна времени изменения этого единственного скрипта, что совершенно не верно.
Динамическое «окно» в закэшированной странице
Ну и напоследок упомяну одну технику, которая может быть полезна в свете кэширования. Если вам хочется закэшировать главную (или любую другую) страницу сайта, однако мешает один маленький блок, который обязательно должен быть динамическим, воспользуйтесь модулем для работы с SSI.
В ту часть страницы, которая должна быть динамической, вставьте вот такой «HTML-комментарий»:
С точки зрения кэша nginx данный комментарий — обычный текст. Он будет сохранен в кэш-файле именно в виде комментария. Однако позже, при прочтения кэша, сработает модуль SSI nginx, который обратится к динамическому URL. Конечно, по адресу /get_user_info/ должен быть PHP-обработчик, который выдает содержимое данного блока. Более подробно данный способ описан в этой статье с Хабра.
Ну и, естественно, не забудьте включить SSI для этой страницы или даже для всего сервера:
Директива SSI include имеет еще одно, крайне важное свойство. Когда на странице встречаются несколько таких директив, то все они начинают обрабатываться одновременно, в параллельном режиме. Так что, если у вас на странице 4 блока, каждый из которых загружается 200мс, в сумме страница будет получена пользователем через 200мс, а не через 800.