ПРОЕКТЫ 


  АРХИВ 


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]

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




20.08.09, 19:28, "opium" <opium@xxxxxxxxxxxxx>:

> 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.



 




Copyright © Lexa Software, 1996-2009.