Php запрет кэширования браузером
Современные браузеры достаточно часто используют в своей работе локальный кэш. Что это означает? Это означает что браузер, получив от сервера html-документ, картинку или другой ресурс, размещает его в своем локальном кэше (проще говоря, записывает полученный ресурс на жесткий диск машины пользователя) и при последующих запросах к такому ресурсу не обращается на сервер, а получает ресурс из локального кеша.
Данная алгоритм работы браузеров резко повышает скорость загрузки html-документов. Так как если ресурс уже загружался, и как следствие расположен в локальном кэше, то время доступа определяется не пропускной способностью канала связи (например, модемного подключения) а скоростью работы жесткого диска.
Однако наряду с достоинствами данный метод так же порождает ряд проблем. В частности большинство начинающих web-программистов, при разработке динамических сайтов, сталкивается с одной и той же проблемой. Суть этой проблемы заключается в том, что вместо повторного обращения на сервер за страницей, запускающей на сервере скрипт, модифицирующий некую информацию, браузер обращается в локальный кэш. И в результате, например трех обращений, происходит не три модификации информации, расположенной на сервере, а только одна.
Для того, что бы заставить браузер каждый раз обращаться за страницей на сервер необходимо запретить браузеру заносить данный ресурс в кэш. Ниже приведены наиболее распространенные методы, запрещающие кэширование или позволяющие его обойти.
Генерация нового URL
Допустим что запрашиваемый ресурс имеет следующий url: test.html?id=7. Как видно из url'а ему передается один параметр. Добавим, например, при помощи JavaScript, в url еще один параметр, а его значением сделаем случайное число. В результате url будет выглядеть следующим образом: test.html?id=7&rnd=0.6700820127538827. Случайный параметр будет каждый раз генерироваться заново. Ниже приводится листинг, демонстрирующий этот подход:
Каждый раз результат такого запроса будет кэшироваться, но так как кэширование производится по всему url, то каждый раз будет получаться новый url и браузер будет вынужден запрашивать с сервера ресурс, так как url двух запросов не будут совпадать в точности.
Поля заголовков
Поле заголовка Expires
Значением данного заголовка является дата, после которой содержимое ресурса устареет. Если пользователь после этой даты обратиться к ресурсу, браузер должен запросить ресурс у сервера, а не из локального кэша.
Поле заголовка Last-Modified
Значением данного заголовка является дата последнего обновления ресурса. Большинство современных браузеров используют следующий алгоритм, если ресурс уже находится в локальном кэше:
- запрашивает с сервера дату последнего обновления ресурса
- сравнивает полученную дату и дату ресурса в локальном кэше
- если ресурс на сервере новее ресурса в кэше - запрашивается ресурс с сервера
Если ресурс, расположенный на сервере, содержит в данном поле текущую дату, то браузер будет каждый раз запрашивать ресурс с сервера, а не из локального кэша. Следующий листинг демонстрирует использование поля заголовка Last-Modified:
Поля заголовка Cache-Control и Pragma
Современные браузеры достаточно часто используют в своей работе локальный кэш. Что это означает? Это означает что браузер, получив от сервера html-документ, картинку или другой ресурс, размещает его в своем локальном кэше (проще говоря, записывает полученный ресурс на жесткий диск машины пользователя) и при последующих запросах к такому ресурсу не обращается на сервер, а получает ресурс из локального кеша.
Данная алгоритм работы браузеров резко повышает скорость загрузки html-документов. Так как если ресурс уже загружался, и как следствие расположен в локальном кэше, то время доступа определяется не пропускной способностью канала связи (например, модемного подключения) а скоростью работы жесткого диска.
Однако наряду с достоинствами данный метод так же порождает ряд проблем. В частности большинство начинающих web-программистов, при разработке динамических сайтов, сталкивается с одной и той же проблемой. Суть этой проблемы заключается в том, что вместо повторного обращения на сервер за страницей, запускающей на сервере скрипт, модифицирующий некую информацию, браузер обращается в локальный кэш. И в результате, например трех обращений, происходит не три модификации информации, расположенной на сервере, а только одна.
Для того, что бы заставить браузер каждый раз обращаться за страницей на сервер необходимо запретить браузеру заносить данный ресурс в кэш. Ниже приведены наиболее распространенные методы, запрещающие кэширование или позволяющие его обойти.
Генерация нового URL
Допустим что запрашиваемый ресурс имеет следующий url: test.html?id=7. Как видно из url'а ему передается один параметр. Добавим, например, при помощи JavaScript, в url еще один параметр, а его значением сделаем случайное число. В результате url будет выглядеть следующим образом: test.html?id=7&rnd=0.6700820127538827. Случайный параметр будет каждый раз генерироваться заново. Ниже приводится листинг, демонстрирующий этот подход:
Каждый раз результат такого запроса будет кэшироваться, но так как кэширование производится по всему url, то каждый раз будет получаться новый url и браузер будет вынужден запрашивать с сервера ресурс, так как url двух запросов не будут совпадать в точности.
Поля заголовков
Поле заголовка Expires
Значением данного заголовка является дата, после которой содержимое ресурса устареет. Если пользователь после этой даты обратиться к ресурсу, браузер должен запросить ресурс у сервера, а не из локального кэша.
Поле заголовка Last-Modified
Значением данного заголовка является дата последнего обновления ресурса. Большинство современных браузеров используют следующий алгоритм, если ресурс уже находится в локальном кэше:
* запрашивает с сервера дату последнего обновления ресурса
* сравнивает полученную дату и дату ресурса в локальном кэше
* если ресурс на сервере новее ресурса в кэше - запрашивается ресурс с сервера
Если ресурс, расположенный на сервере, содержит в данном поле текущую дату, то браузер будет каждый раз запрашивать ресурс с сервера, а не из локального кэша. Следующий листинг демонстрирует использование поля заголовка Last-Modified:
Поля заголовка Cache-Control и Pragma
Сами кэши бываю двух видов — локальные и общие. Локальный это кеш, хранимый непосредственно на диске у клиента, создаваемый и управляемый его браузером. Общий — кэш прокси-сервера организации или провайдера и может состоять из одного или нескольких прокси-серверов. Локальный кеш присутствует, наверное в каждом браузере, общими пользуется значительная часть людей использующих Internet. И если малую часть сайтов сейчас оценивают по расходу трафика, то скорость загрузки — важный критерий, который должен учитываться при разработке Вашего web-проекта.
Для динамических страниц, создаваемых в результате работы PHP-программы, казалось бы, кэширование вредно. Содержание страницы формируются по запросу пользователя на основе какого-либо источника данных. Однако, кэширование может быть полезным. Управляя им Вы можете сделать работу с Вашим сервером комфортнее для пользователя, разрешая загрузку из кэша определенных страниц, предотвращая тем самым их повторную выгрузку с Вашего сервера и экономя пользователю время и трафик.
Кэшировать или нет?
Возможность сохранения в кэш страницы определяется динамичностью информации в источнике данных. Таким образом необходимость использования кэша определяется Вами, исходя из планируемого времени жизни страницы.
Если речь идет о формировании выборки по базе (например, поиск введенного пользователем слова), то такую страница обязательно следует запрашивать с сервера при каждом вызове без использования кэш, так как количество вариантов запрашиваемых слов огромно, а если мы к тому же имеем дело с меняющимся массивом данных, то кэширование бессмысленно. Или речь идет о формировании допустим графика приходящих посетителей (который изменяется с каждым визитом, то есть практически с каждым вызовом), то кеширование уже просто вредно.
Однако, если мы говорим о том же графике но за вчерашний день, то кэширование рекомендуется, так как данные изменяться уже не будут и мы можем экономить себе и пользователю ресурсы и время на загрузку таких страниц помещением их в локальный или общий кэш. Как продолжение этой ситуации формирование графика не в реальном масштабе времени, а ежечасно. Тут Вы можете заранее предсказать дату окончания «срока годности» сформированных данных.
Общие принципы сохранения страниц в кэш.
Несколько общих утверждений характерных не только для PHP-программ:
Таким образом в большинстве ситуаций дополнительных инструкций в программу добавлять не надо. Основные моменты на которые следует обратить внимание можно свести к двум:
- запрет кэширования документов, кэшируемых по умолчанию
- кэширование документов, не подлежащих кэшированию по умолчанию.
Запрет кэширования документов, кэшируемых по умолчанию
I have a php site running in cloud server.When ever i add new files css, js or images the browser is loading the same old js, css and image files stored in cache.
My site has a doctype and meta tag as below
Because of the above doctype and meta code am i loading the same files cached in browser instead of new one
No Cache in all Browsers . You can also do a ?randomGeneratedNumber on the files you dont want to be cached.
6 Answers 6
Except for "max-age=0", those are the headers sent by PHP without specifying the above in my installation.. It seems PHP tries to prevent browser caching by default.
I have a WordPress plugin that sends an alternate theme to old versions of Internet Explorer and it was getting badly tripped up on some caching systems. This post came up on my first Google search. Well played.
Do keep in mind that this cannot be embedded inside of html; this should be at the very top of the page.
Note: If you use session_start() afterwards, it will overwrite your header with Cache-Control: private, max-age=10800, pre-check=10800 because 180 minutes is the default value of session.cache_expire . If you can not avoid starting the session, but you need to disable the cache use session_cache_limiter('private');session_cache_expire(0); .
@thdoan The second parameter of header function is a boolean for replace. The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type.
Here, if you want to control it through HTML: do like below Option 1:
And if you want to control it through PHP: do it like below Option 2:
AND Option 2 IS ALWAYS BETTER in order to avoid proxy based caching issue.
You can try this:
Hopefully it will help prevent Cache, if any!
just the first line should suffice perfectly. 5th line is actually plain wrong and has nothing to do in a server response (it is a request header). sixth line will have no effect whatsovever. i could go on.
The shotgun approach: throw everything at the wall, hope something sticks. As per my comment on the question itself, I can highly recommend grabbing a copy of HTTP: The Definitive Guide and reading the chapter on Caching. Also the RFCs, but reading those is a distinct skill. ("Connection: close" is a hilarious foot-shot to include, disabling efficient pipelining of requests, or will do nothing, but I suspect PHP might actually let that through.)
I had problem with caching my css files. Setting headers in PHP didn't help me (perhaps because the headers would need to be set in the stylesheet file instead of the page linking to it?).
The solution:
Append timestamp as the query part of the URI for the linked file.
(Can be used for css, js, images etc.)
For production (where caching is mostly a good thing):
Or combination of these two:
EDIT:
Or prettier combination of those two:
Arbitrary versions, current timestamps (defeating caching entirely)… but not the one thing that actually makes sense and work, regardless of a "debugging" flag or not. Why aren't you using the actual mtime of the file? Then you'd literally never need to update the PHP, and caches wouldn't become completely and fantastically useless. Or just deliver your statics with a properly configured HTTP server like Nginx or Apache that sets a proper Last-Modified and ETag. Similarly, that type of "debugging" flag already exists… in the browser. (Disable caches, refresh without cache, empty caches, …)
Prevent browser cache is not a good idea depending on the case. Looking for a solution I found solutions like this:
the problem here is that if the file is overwritten during an update on the server, which is my scenario, the cache is ignored because timestamp is modified even the content of the file is the same.
I use this solution to force browser to download assets only if its content is modified:
Yikes! This would be terrible for performance and scalability to always be loading all of your CSS/JS files in the main thread to check their size/hash.
@Dalin Before you cry the tears of Gentoo ricer (a Linux distro known for "going fast" by being excessively compiled from source and architecture-tuned) I'd clock a stat call. Without filesystem cache, 16ns, tops? With cache, reliably < 8ns. Nanoseconds. And on my system MD5 can process 754 MiB/s without blinking. ( openssl speed md5 ) Combined, a 100KB CSS file would have a combined additional overhead of… 129µs (microseconds, 0.1295ms) + 8ns (which does not meaningfully contribute to the final number) = 129µs.
Upon further consideration, it blows me over that the only "correct" answer (with lowest maintenance burden, most accurate/reliable behavior) is both the least voted for, and dismissed in a single comment on such flimsy and unrealistic grounds.
You and I probably work on different websites. But I stand by my comment. If there's dozen's of concurrent threads delivering web pages at any point in time, then I think there's better options that you won't even need to question whether it's scalable. hash_file('md5', $deployment_counter) or hash_file('md5', $cache_clear_counter) are the first that come to mind.
У браузеров есть одна очень важная возможность - это кэширование. Данная функция позволяет резко ускорить процесс загрузки страниц. Однако, иногда кэширование приносит большой вред. Например, у Вас на сайте выводятся какие-нибудь котировки валют, которые меняются постоянно. Представьте, что будет, если у пользователей страница будет в кэше, и изменений котировок они не увидят. И вот как отключить кэширование на PHP, я сейчас и напишу.
Для отключения кэширование на PHP достаточно вставить в код скрипта, который вызывается пользователем, следующие строчки:
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s")." GMT");
header("Cache-Control: no-cache, must-revalidate");
header("Cache-Control: post-check=0,pre-check=0", false);
header("Cache-Control: max-age=0", false);
header("Pragma: no-cache");
?>
Данный код позволяет дать понять самым разным браузерам, что кэшировать данную страницу нельзя. Таким образом, теперь при каждом обновлении все изменения будут браузерами отображены. Но обратите внимание, если Ваш сайт обновляется не каждую минуту, то отключать кэширование не стоит, так как из-за этого скорость загрузки страниц резко сократится.
Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления
Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.
Порекомендуйте эту статью друзьям:
Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):
Она выглядит вот так:
Комментарии ( 2 ):
Михаил,я знаю что функция exec выполняет внешню программу,а что писать в параметрах я низнаю проконсультируйте еня пожалуйста.Спасибо
Читайте также: