Re: FCGI_END_REQUEST и закрытие соединения

[gf pro]

Убедительная просьба убиться об стену ;-) И не смущать неокрепшие умы.

20 августа 2009 г. 20:14 пользователь Denis F. Latypoff
<latypoff at yandex.ru>написал:

>
>
> 20.08.09, 19:28, "opium" <opium at jabber.com.ua>:
>
> > Maxim Dounin  писал(а) в своём письме Thu, 20 Aug 2009
> > 16:59:57 +0300:
> > > Hello!
> > >
> > > On Thu, Aug 20, 2009 at 04:19:39PM +0300, opium wrote:
> > >
> > >>
> > >> Делаю все как описано в
> > >> http://www.fastcgi.com/drupal/node/6?q=node/22#S4
> > >>
> > >> тоесть получаю запрос:
> > >>
> > >> {FCGI_BEGIN_REQUEST,   1, {FCGI_RESPONDER, 0}}
> > >> {FCGI_PARAMS,          1, "\013\002SERVER_PORT80\013\016SER"}
> > >> {FCGI_PARAMS,          1, "VER_ADDR199.170.183.42 ... "}
> > >> {FCGI_PARAMS,          1, ""}
> > >> {FCGI_STDIN,           1, "quantity=100&item=3047936"}
> > >> {FCGI_STDIN,           1, ""}
> > >>
> > >> и даю ответ:
> > >>
> > >>     {FCGI_STDOUT,      1, "Content-type: text/html\r\n\r\n\n
> > >> ... "}
> > >>     {FCGI_STDOUT,      1, ""}
> > >>     {FCGI_END_REQUEST, 1, {0, FCGI_REQUEST_COMPLETE}}
> > >>
> > >> проблема в том, что пока приложение не закроет соединение -- nginx
> > >> ничего
> > >> не отдает http клиенту. с lighttpd все ок. это так и должно быть?
> nginx
> > >> требует закрытия соединения? или ему недостаточно одного
> > >> FCGI_END_REQUEST
> > >> и нужно слать еще чтото?
> > >
> > > Нужно закрыть соединение - как и предписывает отсутствие флага
> > > FCGI_KEEP_CONN в FCGI_BEGIN_REQUEST.
> > >
> > > Ну или брать патчи для постоянных соединений к fastcgi.
> > >
> > Насчет флагов все понял, спасибо. Вопрос к автору: будет ли поддержка
> > FCGI_KEEP_CONN?
>
> Зачем Вам FastCGI? Я в свое время тоже увлекся этим,
> а потом сравнил по скорости и потреблению процессора одно
> и тоже приложение, но с разными протоколами - FastCGI vs HTTP.
> Я думаю все поняли, к чему я. Просто, если уж пишете реализацию
> протокола сами, то лучше напишите парсер HTTP/1.0, ведь приложения
> все равно будет за nginx'ом, а 1.0 реализуется куда более проще
> и надежнее (в плане асинхронной обработки), чем FastCGI.
>
> 2all: плюсуйте :)
>
> --
> br, Denis F. Latypoff.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090821/37bab4e7/attachment.html>