httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pqf 潘庆峰 <...@mailtech.cn>
Subject Re: Re: Anyone interested in a patch to mod_fcgid(with pay)
Date Tue, 23 Jul 2013 01:46:58 GMT
Yes, split process control from mod_fcgid, merge proxy_fcgi(with 
load balance) and mod_fcgid(with authXX support) is a good idea,
admins can use httpd as process manager, or 3rd party process managers as they like.
But don't just make a patch to make mod_fcgid support TCP/IP, it's ugly...



> 
> > Hi, guys
> >    A company need a "TCP/IP patch of mod_fcgid or alternative", and
> > will pay for it, anyone interested? I really like to take it but I
> > don't have too much time... Anyone interested please reply to me and
> > I will forward the email address of them.
> > 
> > ...
> > Neti only listens on TCP/IP socket, it assumes both an authorizer
> > role and a responder role in the Fast CGI request. Here's the 3
> > candidate Apache modules to interface Neti:
> > ...
> >
> > 2. Mod_proxy_fcgi: this module supports TCP socket, it can connect to
> > Neti, but it doesn't support authorizer role. So in the first FCGI
> > request, it forwards the request to Neti as a responder instead of an
> > authorizer, Neti cannot simply let it through without properly
> > authorizing it first, thus the request fails;
> > 
> > 3. Mod_fcgid: this module supports authorizer role while doesn't
> > support TCP connection. We cannot confirm its authorizer role since
> > it doesn't even connect to Neti due to lack of TCP;
> > 
> > So our choice is between either adding authorizer role to
> > mod_proxy_fcgi or adding TCP/IP to mod_fcgid. 
> > 
> > We’re really willing to pay to have this project done, I mean either
> > adding proxy to mod_fcgid or adding authorizer to mod_proxy_fcgi. Are
> > you willing to work on this with reward or do you know anyone else
> > who’s interested in doing so with pay, for example, author of
> > mod_proxy_fcgi? (I cannot find his name)
> 
> No cycles myself at this instant, but it seems overtime to break apart
> the mod_fcgid process-control so that it can then stack on top of a
> single mod_proxy_fcgi communications pipe, dispatched through different
> fcgi-stream methods (including child process stdio), including the
> various authn/authz roles.  It would take more time to refactor it in
> this way, but would get rid of any discrepancies between proxy_fcgi
> and fcgid and serve as a good excuse to draw the remaining mod_fcgid
> development back into trunk/, now that fcgid is generally sufficient
> for 2.2 users.
> 
> 
> 



Mime
View raw message