Использовал output.gzcompress.php для smarty и вот вчера обнаружил досадное недоразумение – одна из страниц после включения этого фильтра перестала отображаться в браузерах (именно отображаться – заголовки приходят верные, контент поступает в «полном объёме», а окно остаётся девственно-чистым), начал разбираться в чём же дело – как тут быть.
Однажды я уже находил «недоразумение» в этом плагине – необходимо было проверять не включен ли debugging, в противном случае IE не мог «распаковать» JS, для debug-консоли, отображал «нелепицу» и при обновлении страницы вообще падал.
Подозрение пало на session_start() – единственное «глобальное» отличие этой страницы от других. И оно (подозрение) оправдалось. Несмотря на то что в плагине есть проверка !headers_sent() , она проходила успешно – в php.ini уже давно output_buffering стоит не 0 ( – 4096). Видимо gzip(deflate)-контент и cookie есть вещи несовместные(возможно дело в порядке отсылки заголовков – читать сейчас RFC не хочется) – пришлось добавить ещё одну проверку в плагин.
UPDATE от 22.12.2005: Каюсь, был дурак – был бы не дурак, всё бы понял – проблема была вовсе не в сессиях, а в том что в скрипте был перевод строки после закрывающего тега “?>”, который, ясен пень, посылался до “зипованного” контента
Очевидно именно так в древности люди придумывали себе суеверия и богов – перешла чёрная кошка дорогу, а тот кто её увидел через полчаса споткнулся и сломал ногу – вывод: кошка приносит несчастья… (“Таракан без ног не слышит”)
Побежал стирать из smarty.wiki свою тупость…
Попутно надо что-нибудь придумать со скриптами – либо нужен некий tool(.sh-скрипт ?) который эти “неожиданные” переводы строк будет убирать(автоматически?) либо нужен плагин для редактора, который этим займётся…
P.S.
Вчера вышла новая очередная – 2.6.11 – версия Smarty – подправлена работа с не так давно вышедшим PHP 5.1, пофиксены баги с кешированием и insert-ами: три часа – полёт нормальный… ещё три и пойду обновлять на production-серверах.