> > > On Mon, 2 Jul 2001, Bill Stoddard wrote:
> > >
> > > > > >cgi on all platforms is broken. Specifically, with the addition of
> > > > > >filters, we have lost the ability to flush partially written buffers
> > > > > >received from CGI scripts to the network.
> > > > > [...]
> > > > > >Apache 2.0 always does a blocking read (in the content length filter)
> > > > >
> > > > > Partial writes to the network from a CGI and content length are
> > > > > mutually exclusive.
> > > >
> > > > No S**t!! :-) That's why it's broken!
> > >
> > > Bill, there is no fix for this. If the content_length filter determines
> > > that a C-L is required, then we can't stream CGI's. It looks like the
> > > problem is simply that we are using the wrong options to apr_bucket_read.
> > > Switch that to a APR_NONBLOCK_READ, and the problem should go away.
> > >
> > > Ryan
> >
> > I don't think changing the read in the content_length filter to nonblocking is the
right
> > solution to this problem because we still need to force the network flush. I will
> > investigate your suggestion though because I might be overlooking something.
>
> This is DSS [dirt simple stupid]. mod_cgi needs to read the *first* part of the
>request
> into a buffer, following the 1.3 convention, and append a flush bucket when it gets
>to
the
> various 1.3 contentions that the buffer should flush.
By the time you do this reliably, you will have a patch that looks a lot like what I
posted. Your pipe read may not return APR_EAGAIN untill you've read, say, 154,265
bytes.
And yes, the patch I posted is DSS :-)
> The C-L filter can STILL interpose
> and block the flush, but if it's simply a chunked http/1.1 connection, this isn't a
problem.
>
But of course.
> > IMO the decision to flush or not and how to read from the pipe should be entirely
> > controlled by mod_cgi. We need a function similar to the old ap_send_fb() code.
>
> No... what you could create, for simplicity, is a cgi_pipe bucket type that has the
>same
> integellegence as 1.3 and ap_send_fb(). It would have to permit morphing into
>another
> bucket type, and might need to learn how to signal a flush itself.
You'll have to convice me that it is better to provide a CGI specific implementation
rather than an implementation that other generators can use. The patch I posted can
easily
be extended to avoid data copies and be made generically useful.
>
> > I also want to play with making the interface between Apache and CGI scripts full
duplex
> > as well (to allow a CGI script to read a large POST request and begin responding to
that
> > POST immediately) which will require controlling the byte stream at the top of the
filter
> > stack as well.
>
> This is big brokenness on 1.3 under Win32 right now. I'd be strongly ++1 to getting
>the
> full duplex logic correct, but only under the caviat that we do so 'with the system'
>and
> we don't simply write dirty hacks around it.
I don't know what you mean by 'with the system'. The key to getting full duplex
working
is making your io calls non-blocking and using a select like call judiciously when
needed.
No magic here at all. We will need to create a new APR primitive, apr_wait_for_event()
for
example that can be implemented appropriately for all platforms. apr_select() will not
work because, AFAIK, it is only portable when used with sockets. select does not work
with file descriptors and pipe handles on all OS'.
Bill
