mod_proxy_fcgi TODO list

[Garrett Rooney <ro...@electricjellyfish.net>]

Just in case other people want to jump in and fix things, here's a
list of stuff I think needs to be done in order to make httpd +
mod_proxy_fcgi a good replacement for the current popular fcgi
solutions (httpd 1.3.x and mod_fcgi and lighttpd + it's fcgi module).

Note that this is split up into things that need to be fixed in
mod_proxy_fcgi and things that will probably need changes in mod_proxy
itself.  I'm also of the opinion that not all of this stuff needs to
be fixed in order for us to merge the current fcgi proxy branch back
into trunk.  If we could fix the majority of the mod_proxy_fcgi
specific stuff that would be enough to justify merging it into trunk.

-garrett

* Stuff that needs to be fixed in mod_proxy_fcgi itself

Figure out what to do about the TZ env variable.

Deal with the (very remote) possibility that the environment is large
enough that it won't fit in the available 32 bits of the length field
in the header.

Fix handle_headers so that it works when the \r\n\r\n is split into
two of the FastCGI records, or when a FastCGI uses \n\n without the
\r's.

Investigate the possibility of making our network I/O nonblocking.

Update the various proxy statistics, so that balancer:// stuff actually works.

Look at cleaning up the FCGI_STDERR logging, after testing with real
world users we may be able to make it look nicer.  Once suitable work
in mod_proxy and execd has been done, look at using unix domain
sockets and execd to start FastCGI processes.

Testing needs to be done with large users of FastCGI like Rails,
Django, Catalyst, and other such frameworks and instructions need to
be written as to how to make them use mod_proxy_fcgi.

* Stuff that needs to be fixed in the mod_proxy framework

Need a way to use a unix domain socket or a pipe instead of a TCP socket.

Need to generalize the ProxyPass options stuff, so that back end
modules can have config options without having to hack it into
mod_proxy itself.

Re: mod_proxy_fcgi TODO list

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/15/06, Graham Leggett <mi...@sharp.fm> wrote:
> Garrett Rooney wrote:
>
> > Need a way to use a unix domain socket or a pipe instead of a TCP socket.
>
> Isn't this a filter problem?
>
> mod_proxy in theory should not care that the source is a socket beyond
> maybe knowing to insert the right filter into the stack.

Well, mod_proxy currently creates the socket itself via
apr_socket_create based on the host and port it's been given via
ProxyPass.  We're going to need a way to tell it to use a unix domain
socket located at a certain path, that's all I mean by that change.  I
have some patches hacked together to make it use the apr_portable.h
stuff to do it, it isn't that hard, it's really just a matter of
figuring out how it should be configured to do so.

-garrett

Re: mod_proxy_fcgi TODO list

[Graham Leggett <mi...@sharp.fm>]

Garrett Rooney wrote:

> Need a way to use a unix domain socket or a pipe instead of a TCP socket.

Isn't this a filter problem?

mod_proxy in theory should not care that the source is a socket beyond 
maybe knowing to insert the right filter into the stack.

Regards,
Graham
--

Re: mod_proxy_fcgi TODO list

[Garrett Rooney <ro...@electricjellyfish.net>]

On 1/14/06, Garrett Rooney <ro...@electricjellyfish.net> wrote:

> Fix handle_headers so that it works when the \r\n\r\n is split into
> two of the FastCGI records, or when a FastCGI uses \n\n without the
> \r's.

This is done as of r371428.

-garrett