Re: Проблема с fastcgi

[David Mzareulyan <david@xxxxxxxx>]

Hello Igor,

> On Sat, Mar 08, 2008 at 04:58:52PM +0000, David Mzareulyan wrote:
>
> > Игорь, а зачем это разрешать/запрещать отдельным ключом? Какие
> > проблемы
> > могут быть с постами в статику?
> > Ну то есть, понятно, что если там в самом деле статика, то надо
> > выдать
> > ошибку. Но если там 404-й обработчик -- почему нельзя доверить ему
> > решение?
> В принципе, это решается так:
>
> error_page  404 405 = @fallback;
Самое естественное решение, да, но ведь сейчас-то это не работает.

Просто по логике (я не знаю внутренностей nginx, так что могу сказать глупость): 
пришёл POST-запрос, мы нашли для него локацию. Если по этой локации найден 
статический файл, то выдаём 405. Если не найден, то мы переходим на локацию, 
соответствующую 404-й ошибке и процедура повторяется. Рано или поздно кто-то 
или обработает запрос или выбросит ошибку.
Поэтому нелогично выглядит, когда при POST-запросе управление не переходит 
на @fallback. Ну не нашёлся файл -- так ведь ясно сказано, куда идти, если 
не нашёлся.
> Тем не менее, ситуация неоднозначная - POST в статику, как правило,
> бессмысленен и сервера (тот же Апач) для него возращают 405.
>
> Однако, есть как минимум два случая, когда POST можно разрешить:
>
> 1) статический файл проходит через SSI, который делает вставку с
> сервера,
> понимающего POST.
Хм. Вот о таком я не подумал. Это, наверное, единственный вариант, когда 
может понадобиться явное разрешение/запрещение поста в статику -- потому 
что только в этом случае nginx делает какую-то интерпретацию файла.
Может быть, разрешать пост всегда для ssi on? Хотя, наверное, это неправильно.

> 2) статическая страница о профикалктических работах, которая должна
> тупо
> показываться в том числе и для POST'а.
Ну, это довольно специальный случай... не так трудно явно указать страницу 
с ошибкой.
--
С уважением
Давид Мзареулян
david@xxxxxxxx