Была похожая проблема на опенсорсных форумных движках. Вылечили отключением gzip.<br><br><div><span class="gmail_quote">09.02.08, <b class="gmail_sendername">David Mzareulyan</b> <<a href="mailto:david@hiero.ru">david@hiero.ru</a>> написал(а):</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
У меня достаточно сложные для описания условия задачи, так что извините за "многабукв".<br><br>Имеется сайт (на php) со своим движком, шаблонами и т. д. Отдельно есть раздел документов, в качестве движка которого используется dokuwiki. Нужно чтобы страницы dokuwiki показывались в стиле основного сайта. Dokuwiki, к сожалению, сам по себе не даёт возможности "встроить" себя в другой фреймворк. Дело осложняется тем, что вики выдаёт страницы как по GET так и по POST-запросам. Постоянно поддерживать синхронность шаблонов dokuwiki и основного движка сложно и муторно, поэтому я использую следущий метод:<br>
<br>В конфиге сервера в блоке, отвечающем за dokuwiki, включён SSI, а в самой dokuwiki используется шаблон, который генерирует страницу типа:<br><br><!--# block name="title" --><?=$pageTitle?><!--# endblock --><br>
<!--# block name="meta" --><?=$pageMeta?><!--# endblock --><br><!--# block name="body" --><?=$pageBody?><!--# endblock --><br><!--# include virtual="/wiki-template" --><br>
<br>Адрес "/wiki-template" обрабатывается уже основным фреймворком:<br><br>location = /wiki-template { ssi on; gzip off; fastcgi_pass unix:/var/run/php-fpm.sock; }<br><br>...и выдаёт в дизайне основного сайта страницу, в которой в нужных местах стоят блоки:<br>
<br><!--# include virtual="/no-content" stub="title" --><br><!--# include virtual="/no-content" stub="meta" --><br><!--# include virtual="/no-content" stub="body" --><br>
<br>/no-content имеет следующий конфиг:<br>location = /no-content { return 204; }<br><br>В результате include заполняются значениями блоков, определённых в основной SSI-странице.<br><br>Я знаю, что это выглядит громоздко, но как эту задачу решить по-другому, я не придумал. Зато такая схема позволяет спокойно менять шаблоны основного сайта и быть уверенным, что раздел, работающий на dokuwiki всегда будет отображаться корректно.<br>
<br>Всё это работает на GET-запросах (то есть, при обычном чтении страниц всё нормально). Но, как я писал выше, dokuwiki в процессе работы возвращает страницы и в ответ на POST-запросы (также оформленные через всю эту машинерию). Например, при редактировании wiki-страниц.<br>
<br>И вот тут случается что-то странное. Некоторые (всегда одни и те же) POST-запросы отрабатываются нормально, и выдают правильно оформленные страницы. А некоторые -- отрабатывают, формируют SSI-страницу, но <!--# include virtual="/wiki-template" --> (именно этот инклюд) на ней почему-то выдаёт 502-ю ошибку. В дебаг-логе это выглядит так:<br>
<br>2008/02/09 16:50:26 [crit] 18077#0: *60159 sendfile() failed (9: Bad file descriptor) while sending request to upstream, client: <a href="http://85.141.150.193">85.141.150.193</a>, server: <a href="http://lori.ru">lori.ru</a>, request: "POST /doc/doku.php HTTP/1.1", subrequest: "/wiki-template", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "<a href="http://lori.ru">lori.ru</a>", referrer: "<a href="http://lori.ru/doc/forauthors">http://lori.ru/doc/forauthors</a>"<br>
<br>Это единственная разница в логах успешного и неуспешного POST-запроса. В логах php-fpm пусто, до php-обработчика /wiki-template запрос вообще не доходит.<br><br>В чём тут может быть дело и в какую сторону тут следует копать?<br>
<br>Прилагаю фрагменты дебаг-лога в районе подзапроса к /wiki-template.<br><br><br>--<br>С уважением<br>Давид Мзареулян<br><a href="mailto:david@hiero.ru">david@hiero.ru</a></blockquote></div><br>