httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Mon, 02 Jul 2001 19:41:56 GMT
> > > On Mon, 2 Jul 2001, Bill Stoddard wrote:
> > >
> > > > > >cgi on all platforms is broken.  Specifically, with the addition
> > > > > >filters, we have lost the ability to flush partially written
> > > > > >received from CGI scripts to the network.
> > > > > [...]
> > > > > >Apache 2.0 always does a blocking read (in the content length
> > > > >
> > > > > 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
> > 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
> 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
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
> > as well (to allow a CGI script to read a large POST request and begin responding
> > POST immediately) which will require controlling the byte stream at the top of the
> > stack as well.
> This is big brokenness on 1.3 under Win32 right now.  I'd be strongly ++1 to getting
> full duplex logic correct, but only under the caviat that we do so 'with the system'
> 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'.


View raw message