обьясните мне пожалуйста, почему все говорят «хидер»? ведь header он читается «хедер» или «хэдер», но никак не «хидер». извините за занудство, просто сто раз слышал, ухо режет
чудесная логика. если бы вы учили только, скажем, иврит, вы бы, наверное, говорили «рдх» и тоже ожидали бы, что вас все поймут ;-)
«хидеры» и «хеадеры» — это, в общем, показательно: если человек не может запомнить (или даже принципиально не хочет запоминать) элементарные правила произношения слов, которые он волей-неволей должен часто употреблять, требовать от него глубокого знания, допустим, programming patterns (которые тоже хорошо бы применять в повседневной жизни) довольно наивно.
Уважаемый, Вы придираетесь. У нас страна никак не может определиться, надо ли писать «веб» или «вэб». Программирование — это внимание к мелочам, да, а не пустые разговоры «на тему».
я считаю, что на качество программирования влияет: а) способность признавать свои ошибки, а не защищать их с пеной у рта б) стремление в общем случае делать так, как правильно, а не так, как «хочется».
А повыше почитать не судьба? Я уже и на яндекс слазал, и в гугл, и транскрипцию написал, а также послушал как произносится, что еще нужно сделать? ;)
Сдается мне, что высот в программировании Вы еще не добились, раз размениваетесь на такие мелочи. Лучше бы по существу что-нибудь написали, честное слово, вместо того, чтоб «эфир» засорять.
при каждом запросе обсчитывать md5-хэш файла — дорогое удовольствие; заголовок (давайте будем так, чтобы без холиваров) «cache-control» в случае, если кэш срабатывает, выдается дважды — зачем?
в целом решение нормальное такое. но для кэширования статики (особенно раз она у вас генерируется автоматически) обычно просто используют большое значение Expires, а ссылка на файл автоматически переименовывается при каждом изменении (с подстановкой того же filemtime(), при этом через mod_rewrite делаете так, чтобы ссылки вида /css/index.1223427651.css и /css/index.1223425897.css вели на один и тот же файл). смысл — экономите пользователю запрос на сервер. а ваше решение подходит больше для кэширования собственно HTML-страниц, которые время от времени могут поменяться. на жестко динамические страницы такое кэширование ставить смысла вообще нет.
Тут есть нюансы, которые тоже следует учесть на всякий случай:
— Если PHP через CGI будет работать а не через модуль Apache, HTTP_IF_MODIFIED_SINCE там не будет.
— header(«LAST-MODIFIED: ». gmdate(«D, d M Y H:i:s», $time). " GMT"); Не очень хорошо подсовывать GMT жёстко, многие серваки с UTC работают, ошибко имхо.
Да и стоит подумать о HTTP/1.1, актуально всёж.
Но это только советы, если универсальность нужна)
у меня обычно обратная проблема — при изменении скрипта часто приходится подгружать его браузером напрямую, так как «внедрённый» он грузится из кэша, сколько ты ему не жми refresh
header("Expires: Tue, 1 Jan 2000 00:00:00 GM"); // любая дата из прошлого
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); // текущая дата
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Pragma: no-cache");
Но в любом случае перед тем, как пользоваться фреймворком, неплохо бы разбираться, как он что делает. Хотя бы в общих чертах. Чтобы не было холивара, я поясню — при использовании jQuery не надо лазать в код по поводу и без, но для общего развития полезно иметь представление об ее внутреннем устройстве. Так же и с классом mysql например. Надо сначала немного поработать с БД через встроенные функции, а уж потом, имея знания, переходить на фреймворк. Но никто не отменял правило, что хорош тот фреймворк, который так задокументирован и сделан, что избавляет от необходимости себя изучать.
> Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();
А как вы думаете, зачем разработчики это сделали, а? Неужели только для того, чтобы вам напакостить?
когда используется сессия, речь обычно идет о страницах, вроде личного профиля, или например просмотра личной почты, то есть private страницах. Такие страницы *не должны* кешироваться промужуточными прокси-серверами (чтобы не попасть другому, неавторизованному, пользователя, ставится, cahce-control:private), и браузером (так как генерируются как правило динамически), поэтому PHP и ставит соответствующие заголовки. А вам вдруг в голову приперло все это сломать и сделать по-своему. Но-но. Мучайтесь потом сами с глюками кеширования у клиентов, удачи вам.
Мне проще сессию запускать в каждом скрипте, и блокировать ее в 2х нужных. Чем наоборот :) Если вы имели ввиду, что может ее вообще не стартовать — ради 2 скриптов писать грабли с запуском или не-запуском сессии… вобщем мне проще прозрачно контролировать кеширование вручную :)
Кеширование обычными средствами