Логично предположить, что когда буфер забит, а запись в него все идет и идет, то РНР начинает его отправлять, и ждет пока юзер его не заберет, соответственно ничего нового туда не будет записано. Но это мои догадки…
Суть, как я понял, в том, что РНР притормаживает при отдаче print'ов и пока не отдаст их юзеру дальше не выполняется, так?
А если, допустим, вначале скрипта поставить размер буфера на 30-40К, включить ob_start и держать его до самого конца ничего не отдавая, и отдать уже в самом конце одним куском в самом-самом конце работы — решит ли это проблему?
Идиотский стандарт такой из-за картинок. Если в режиме border-box картинке 100×100 прописать border: 5px solid black, то результирующий размер будет 110×110, а это как раз поведение context-box.
Вот и получается, что в модели border-box есть важная логическая нестыковка, видимо от этого парни из W3C и отталкивались.
А теперь личное мнение: ради одного дурацкого элемента IMG заставлять все элементы работать в не-интуитивном ключе было безумием. Оставили бы граблю только для IMG, а для остальных сделали бы как логичнее…
Мне проще сессию запускать в каждом скрипте, и блокировать ее в 2х нужных. Чем наоборот :) Если вы имели ввиду, что может ее вообще не стартовать — ради 2 скриптов писать грабли с запуском или не-запуском сессии… вобщем мне проще прозрачно контролировать кеширование вручную :)
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 например. Надо сначала немного поработать с БД через встроенные функции, а уж потом, имея знания, переходить на фреймворк. Но никто не отменял правило, что хорош тот фреймворк, который так задокументирован и сделан, что избавляет от необходимости себя изучать.
А повыше почитать не судьба? Я уже и на яндекс слазал, и в гугл, и транскрипцию написал, а также послушал как произносится, что еще нужно сделать? ;)
Сдается мне, что высот в программировании Вы еще не добились, раз размениваетесь на такие мелочи. Лучше бы по существу что-нибудь написали, честное слово, вместо того, чтоб «эфир» засорять.
Уважаемый, Вы придираетесь. У нас страна никак не может определиться, надо ли писать «веб» или «вэб». Программирование — это внимание к мелочам, да, а не пустые разговоры «на тему».
А если, допустим, вначале скрипта поставить размер буфера на 30-40К, включить ob_start и держать его до самого конца ничего не отдавая, и отдать уже в самом конце одним куском в самом-самом конце работы — решит ли это проблему?
Вот и получается, что в модели border-box есть важная логическая нестыковка, видимо от этого парни из W3C и отталкивались.
А теперь личное мнение: ради одного дурацкого элемента IMG заставлять все элементы работать в не-интуитивном ключе было безумием. Оставили бы граблю только для IMG, а для остальных сделали бы как логичнее…
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 например. Надо сначала немного поработать с БД через встроенные функции, а уж потом, имея знания, переходить на фреймворк. Но никто не отменял правило, что хорош тот фреймворк, который так задокументирован и сделан, что избавляет от необходимости себя изучать.
Расскажите вкратце про либу :)
Кстати в данной статье это оправдано — внимание привлекают.
«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 в описании параметров.
Насчет таких суровых ссылок — ну не знаю, мне такой вариант не очень нравится, хотя он и вполне жизнеспособен.
Для чисто динамических страниц применять кеширование в таком виде — это надо конечно додуматься :)
Сдается мне, что высот в программировании Вы еще не добились, раз размениваетесь на такие мелочи. Лучше бы по существу что-нибудь написали, честное слово, вместо того, чтоб «эфир» засорять.
Это конечно стёб, думаю тему написания слова «header» можно закрыть.
«You can use HTTP's etags and last modified dates to ensure that you're not sending the browser data it already has cached»