ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • To: nginx-ru@xxxxxxxxx
  • Subject: Проблема с SSI при некоторых POST-запросах
  • From: David Mzareulyan <david@xxxxxxxx>
  • Date: Sat, 9 Feb 2008 15:13:49 +0000 (UTC)

This is a multi-part message in MIME format.
У меня достаточно сложные для описания условия задачи, так что извините за 
"многабукв".

Имеется сайт (на 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@xxxxxxxx

Attachment: ssi-success.log
Description: Binary data

Attachment: ss-fail.log
Description: Binary data



 




Copyright © Lexa Software, 1996-2009.