Проблема с SSI при некоторых POST-запросах

[David Mzareulyan]

У меня достаточно сложные для описания условия задачи, так что извините за "многабукв".

Имеется сайт (на php) со своим движком, шаблонами и т. д. Отдельно есть раздел документов, в качестве движка которого используется dokuwiki. Нужно чтобы страницы dokuwiki показывались в стиле основного сайта. Dokuwiki, к сожалению, сам по себе не даёт возможности "встроить" себя в другой фреймворк. Дело осложняется тем, что вики выдаёт страницы как по GET так и по POST-запросам. Постоянно поддерживать синхронность шаблонов dokuwiki и основного движка сложно и муторно, поэтому я использую следущий метод:

В конфиге сервера в блоке, отвечающем за dokuwiki, включён SSI, а в самой dokuwiki используется шаблон, который генерирует страницу типа:

<!--# block name="title" --><?=$pageTitle?><!--# endblock -->
<!--# block name="meta" --><?=$pageMeta?><!--# endblock -->
<!--# block name="body" --><?=$pageBody?><!--# endblock -->
<!--# include virtual="/wiki-template" -->

Адрес "/wiki-template" обрабатывается уже основным фреймворком:

location = /wiki-template { ssi on; gzip off; fastcgi_pass   unix:/var/run/php-fpm.sock; }

...и выдаёт в дизайне основного сайта страницу, в которой в нужных местах стоят блоки:

<!--# include virtual="/no-content" stub="title" -->
<!--# include virtual="/no-content" stub="meta" -->
<!--# include virtual="/no-content" stub="body" -->

/no-content имеет следующий конфиг: 
location = /no-content { return 204; }

В результате include заполняются значениями блоков, определённых в основной SSI-странице.

Я знаю, что это выглядит громоздко, но как эту задачу решить по-другому, я не придумал. Зато такая схема позволяет спокойно менять шаблоны основного сайта и быть уверенным, что раздел, работающий на dokuwiki всегда будет отображаться корректно.

Всё это работает на GET-запросах (то есть, при обычном чтении страниц всё нормально). Но, как я писал выше, dokuwiki в процессе работы возвращает страницы и в ответ на POST-запросы (также оформленные через всю эту машинерию). Например, при редактировании wiki-страниц.

И вот тут случается что-то странное. Некоторые (всегда одни и те же) POST-запросы отрабатываются нормально, и выдают правильно оформленные страницы. А некоторые -- отрабатывают, формируют SSI-страницу, но <!--# include virtual="/wiki-template" --> (именно этот инклюд) на ней почему-то выдаёт 502-ю ошибку. В дебаг-логе это выглядит  так:

2008/02/09 16:50:26 [crit] 18077#0: *60159 sendfile() failed (9: Bad file descriptor) while sending request to upstream, client: 85.141.150.193, server: lori.ru, request: "POST /doc/doku.php HTTP/1.1", subrequest: "/wiki-template", upstream: "fastcgi://unix:/var/run/php-fpm.sock:", host: "lori.ru", referrer: "http://lori.ru/doc/forauthors"

Это единственная разница в логах успешного и неуспешного POST-запроса. В логах php-fpm пусто, до php-обработчика /wiki-template запрос вообще не доходит.

В чём тут может быть дело и в какую сторону тут следует копать?

Прилагаю фрагменты дебаг-лога в районе подзапроса к /wiki-template.


-- 
С уважением
Давид Мзареулян
david at hiero.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ssi-success.log
Type: application/octet-stream
Size: 3950 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20080209/03378bd3/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ss-fail.log
Type: application/octet-stream
Size: 4120 bytes
Desc: not available
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20080209/03378bd3/attachment-0001.obj>