httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
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
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


Mime
View raw message