Comments 41
А зачем одновременно ETAG и LAST-MODIFIED?
обьясните мне пожалуйста, почему все говорят «хидер»? ведь header он читается «хедер» или «хэдер», но никак не «хидер». извините за занудство, просто сто раз слышал, ухо режет
Да как-то устоялось уже так… Правильное произношение — 
А тут можно послушать www.google.com/dictionary?langpair=en|ru&q=header
Ну так как я везде учил только немецкий, то я говорю хеадер и все понимают, так что вообще не вижу проблемы.
чудесная логика. если бы вы учили только, скажем, иврит, вы бы, наверное, говорили «рдх» и тоже ожидали бы, что вас все поймут ;-)
«хидеры» и «хеадеры» — это, в общем, показательно: если человек не может запомнить (или даже принципиально не хочет запоминать) элементарные правила произношения слов, которые он волей-неволей должен часто употреблять, требовать от него глубокого знания, допустим, programming patterns (которые тоже хорошо бы применять в повседневной жизни) довольно наивно.
«хидеры» и «хеадеры» — это, в общем, показательно: если человек не может запомнить (или даже принципиально не хочет запоминать) элементарные правила произношения слов, которые он волей-неволей должен часто употреблять, требовать от него глубокого знания, допустим, programming patterns (которые тоже хорошо бы применять в повседневной жизни) довольно наивно.
Логика отличная — не заморачиваться по пустякам.
программирование — это внимание к мелочам. на эту тему можно почитать Дейкстру, например. главное — не перепутайте с «Дийсктрой» и «Дайкстрой» ;-)
Уважаемый, Вы придираетесь. У нас страна никак не может определиться, надо ли писать «веб» или «вэб». Программирование — это внимание к мелочам, да, а не пустые разговоры «на тему».
То есть ты считаешь, что на качество программирования влияет то как ты произносишь слово header?
я считаю, что на качество программирования влияет: а) способность признавать свои ошибки, а не защищать их с пеной у рта б) стремление в общем случае делать так, как правильно, а не так, как «хочется».
А повыше почитать не судьба? Я уже и на яндекс слазал, и в гугл, и транскрипцию написал, а также послушал как произносится, что еще нужно сделать? ;)
Сдается мне, что высот в программировании Вы еще не добились, раз размениваетесь на такие мелочи. Лучше бы по существу что-нибудь написали, честное слово, вместо того, чтоб «эфир» засорять.
Сдается мне, что высот в программировании Вы еще не добились, раз размениваетесь на такие мелочи. Лучше бы по существу что-нибудь написали, честное слово, вместо того, чтоб «эфир» засорять.
так я не вам и пишу, что за эгоцентризм? ;-)
по существу — окей, раз просите.
при каждом запросе обсчитывать md5-хэш файла — дорогое удовольствие; заголовок (давайте будем так, чтобы без холиваров) «cache-control» в случае, если кэш срабатывает, выдается дважды — зачем?
в целом решение нормальное такое. но для кэширования статики (особенно раз она у вас генерируется автоматически) обычно просто используют большое значение Expires, а ссылка на файл автоматически переименовывается при каждом изменении (с подстановкой того же filemtime(), при этом через mod_rewrite делаете так, чтобы ссылки вида /css/index.1223427651.css и /css/index.1223425897.css вели на один и тот же файл). смысл — экономите пользователю запрос на сервер. а ваше решение подходит больше для кэширования собственно HTML-страниц, которые время от времени могут поменяться. на жестко динамические страницы такое кэширование ставить смысла вообще нет.
при каждом запросе обсчитывать md5-хэш файла — дорогое удовольствие; заголовок (давайте будем так, чтобы без холиваров) «cache-control» в случае, если кэш срабатывает, выдается дважды — зачем?
в целом решение нормальное такое. но для кэширования статики (особенно раз она у вас генерируется автоматически) обычно просто используют большое значение Expires, а ссылка на файл автоматически переименовывается при каждом изменении (с подстановкой того же filemtime(), при этом через mod_rewrite делаете так, чтобы ссылки вида /css/index.1223427651.css и /css/index.1223425897.css вели на один и тот же файл). смысл — экономите пользователю запрос на сервер. а ваше решение подходит больше для кэширования собственно HTML-страниц, которые время от времени могут поменяться. на жестко динамические страницы такое кэширование ставить смысла вообще нет.
В первый раз «CACHE-CONTROL» сбрасывается, это отменяет то, что выдается после вызова session_start(); второй заголовок отменяет первый, потому что
«The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in FALSE as the second argument you can force multiple headers of the same type.» © ru2.php.net/header в описании параметров.
Насчет таких суровых ссылок — ну не знаю, мне такой вариант не очень нравится, хотя он и вполне жизнеспособен.
Для чисто динамических страниц применять кеширование в таком виде — это надо конечно додуматься :)
«The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in FALSE as the second argument you can force multiple headers of the same type.» © ru2.php.net/header в описании параметров.
Насчет таких суровых ссылок — ну не знаю, мне такой вариант не очень нравится, хотя он и вполне жизнеспособен.
Для чисто динамических страниц применять кеширование в таком виде — это надо конечно додуматься :)
Угу замечательно, только это относится ко всем профессиям и вообще не ноносится к произношению слова хеадер.
Немцы, кстати, произносят английские названия не обнемечивая, т.е. «сервер» произносится как «сёрвер», или точнее, как «server» и т.п.
ай хороший человек, как понимаю!
Поправьте, пожалуйста, тэги. Нужно через запятую.
Пустые хедеры крешат некоторые нерадивые прокси сервера :)
haproxy, например, вылетал. Вроде пофиксили.
haproxy, например, вылетал. Вроде пофиксили.
Тут есть нюансы, которые тоже следует учесть на всякий случай:
— Если 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, актуально всёж.
Но это только советы, если универсальность нужна)
— Если 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
А это не тоже самое, что давно с успехом делает либа Minify? правда она еще много чего умеет помимо
Да, видел, но так и не дошли руки скачать ее…
Но в любом случае перед тем, как пользоваться фреймворком, неплохо бы разбираться, как он что делает. Хотя бы в общих чертах. Чтобы не было холивара, я поясню — при использовании jQuery не надо лазать в код по поводу и без, но для общего развития полезно иметь представление об ее внутреннем устройстве. Так же и с классом mysql например. Надо сначала немного поработать с БД через встроенные функции, а уж потом, имея знания, переходить на фреймворк. Но никто не отменял правило, что хорош тот фреймворк, который так задокументирован и сделан, что избавляет от необходимости себя изучать.
Расскажите вкратце про либу :)
Но в любом случае перед тем, как пользоваться фреймворком, неплохо бы разбираться, как он что делает. Хотя бы в общих чертах. Чтобы не было холивара, я поясню — при использовании jQuery не надо лазать в код по поводу и без, но для общего развития полезно иметь представление об ее внутреннем устройстве. Так же и с классом mysql например. Надо сначала немного поработать с БД через встроенные функции, а уж потом, имея знания, переходить на фреймворк. Но никто не отменял правило, что хорош тот фреймворк, который так задокументирован и сделан, что избавляет от необходимости себя изучать.
Расскажите вкратце про либу :)
да штука то простая, на сайте все нормально написано. Делать перевод не интересно=)
кстати, про неплохо понимать что делает
> Опытным путем было установлено, что PHP устанавливает хидеры запрета кеширования при использовании функции session_start();
А как вы думаете, зачем разработчики это сделали, а? Неужели только для того, чтобы вам напакостить?
когда используется сессия, речь обычно идет о страницах, вроде личного профиля, или например просмотра личной почты, то есть private страницах. Такие страницы *не должны* кешироваться промужуточными прокси-серверами (чтобы не попасть другому, неавторизованному, пользователя, ставится, cahce-control:private), и браузером (так как генерируются как правило динамически), поэтому PHP и ставит соответствующие заголовки. А вам вдруг в голову приперло все это сломать и сделать по-своему. Но-но. Мучайтесь потом сами с глюками кеширования у клиентов, удачи вам.
А как вы думаете, зачем разработчики это сделали, а? Неужели только для того, чтобы вам напакостить?
когда используется сессия, речь обычно идет о страницах, вроде личного профиля, или например просмотра личной почты, то есть private страницах. Такие страницы *не должны* кешироваться промужуточными прокси-серверами (чтобы не попасть другому, неавторизованному, пользователя, ставится, cahce-control:private), и браузером (так как генерируются как правило динамически), поэтому PHP и ставит соответствующие заголовки. А вам вдруг в голову приперло все это сломать и сделать по-своему. Но-но. Мучайтесь потом сами с глюками кеширования у клиентов, удачи вам.
Ой, мой сайт :) Правда ссылка не туда.
Sign up to leave a comment.
Кеширование обычными средствами