[PATCH] mod_proxy_fcgi - send stdin data to fastcgi process

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

And here we have today's mod_proxy_fcgi patch, support for sending the
FASTCGI_STDIN records (which contain the data from the body of the
request) to the fastcgi process.  Again, basic testing with a Ruby
fastcgi program indicates that it's at least minimally functional

Log follows, patch attached.

-garrett

Add support for sending the FASTCGI_STDIN stream of data to the fastcgi
process.

* modules/proxy/mod_proxy_fcgi.c
  (fill_in_header): New helper function.
  (send_begin_request, send_environment): Fix formatting, use fill_in_header.
  (MAX_INPUT_BYTES): New constant.
  (send_stdin): New function.
  (fcgi_do_request): Send the body of the request via send_stdin.

Re: [PATCH] mod_proxy_fcgi - send stdin data to fastcgi process

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

On 12/26/05, Paul Querna <ch...@force-elite.com> wrote:
> Garrett Rooney wrote:
> > And here we have today's mod_proxy_fcgi patch, support for sending the
> > FASTCGI_STDIN records (which contain the data from the body of the
> > request) to the fastcgi process.  Again, basic testing with a Ruby
> > fastcgi program indicates that it's at least minimally functional
> >
> > Log follows, patch attached.
>
> I do have some issues with this in the long term:
>
> 1) 1024 is tiny. Prolly should try something much higher.

Yah, I just picked an arbitrary buffer size.

> 2) It doesn't check for a reply from the FastCGI backend.  According to
> the spec, a reply can be sent, before STDIN is finished.  This could get
> kinda complicated, but I believe what we should do is Poll the socket
> for both read and write.  When writable, continue a non-blocking write
> to it.  When read able.. hopefully read something from the backend,
> which may again, come before we are done sending STDIN.

See the next patch (to be posted in a few minutes) which converts this
to using apr_poll so it can handle interleaved reading and writing of
records.  Note that it won't yet switch to actual non-blocking
reads/writes, but it will move us in that direction.

> Anyways. These are things we should fix before merging back to trunk,
> but I just committed your patch to the dev branch in r359183.  Its
> progress :)
>
> Thanks Again,

Thanks for committing it!

-garrett

Re: [PATCH] mod_proxy_fcgi - send stdin data to fastcgi process

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

On 12/26/05, Justin Erenkrantz <ju...@erenkrantz.com> wrote:
> On Mon, Dec 26, 2005 at 11:28:45PM -0800, Paul Querna wrote:
> > 1) 1024 is tiny. Prolly should try something much higher.
>
> How about using AP_IOBUFSIZE instead?  -- justin

Makes sense to me.  The next patch switches to using that for the buffer sizes.

-garrett

Re: [PATCH] mod_proxy_fcgi - send stdin data to fastcgi process

[Justin Erenkrantz <ju...@erenkrantz.com>]

On Mon, Dec 26, 2005 at 11:28:45PM -0800, Paul Querna wrote:
> 1) 1024 is tiny. Prolly should try something much higher.

How about using AP_IOBUFSIZE instead?  -- justin

Re: [PATCH] mod_proxy_fcgi - send stdin data to fastcgi process

[Paul Querna <ch...@force-elite.com>]

Garrett Rooney wrote:
> And here we have today's mod_proxy_fcgi patch, support for sending the
> FASTCGI_STDIN records (which contain the data from the body of the
> request) to the fastcgi process.  Again, basic testing with a Ruby
> fastcgi program indicates that it's at least minimally functional
> 
> Log follows, patch attached.

I do have some issues with this in the long term:

1) 1024 is tiny. Prolly should try something much higher.

2) It doesn't check for a reply from the FastCGI backend.  According to 
the spec, a reply can be sent, before STDIN is finished.  This could get 
kinda complicated, but I believe what we should do is Poll the socket 
for both read and write.  When writable, continue a non-blocking write 
to it.  When read able.. hopefully read something from the backend, 
which may again, come before we are done sending STDIN.

Anyways. These are things we should fix before merging back to trunk, 
but I just committed your patch to the dev branch in r359183.  Its 
progress :)

Thanks Again,

-Paul