httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: cvs commit: httpd-2.0 STATUS
Date Mon, 02 Jul 2001 21:05:41 GMT

> > > > 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()
> >
> > You can't leave this up to mod_cgi.  As soon as the data leaves mod_cgi,
> > it is officially out of mod_cgi's hands.  Later filters must just work
> > correctly.
> >
> > > Hi Bill,
> > > I was wondering if there was a generic way of doing this in a generic
> > > fashion so that ALL dynamic content modules (perl/jk/proxy etc)
> > > would be affected (maybe putting it into the socket/pipe bucket read
> > > functions)
> >
> > IMNSHO, the correct way to do this, is to fix the C-L filter, not modify
> > the generator.  The filter is doing a blocking read, when it should do a
> > non-blocking read.  The C-L filter, in other words, is getting in the way
> > of getting things done, instead of acting innocently.  The whole point of
> > always going through the C-L filter, is that it should never delay
> > information.
> >
> > The patch below is relying on all filters to honor the FLUSH bucket type,
> > which is incorrect.  Just make the core filters work properly, and you
> > will solve this problem.
> >
> I don't think your suggestion will solve the problem.  Here is a simple CGI script to
> demonstrate...
> #!e:/ntreskit/perl/perl.exe
> $|=1;
> print "Content-type: text/html\n\n";
> print "WooHoo... Going to sleep for 5 seconds...<BR>\n";
> sleep 5;
> print "I am awake now...<BR>\n";
> while (($key, $val) = each %ENV) {
>  print "$key = $val<BR>\n";
> }
> When the CGI script is run, I want to see the following string in the
> browser -immediately-:
> "WooHoo... Going to sleep for 5 seconds..."

You are correct, my suggestion won't fix this.  It will solve the problem
of the C-L filter getting the data before the CGI sleeps for 5 seconds,
which is the first half of the problem.  The second half is a bit harder
to see, but easy to solve.  That is, how do you get the data from the C-L
filter to the user.  I would suggest something as simple as

    if (apr_bucket_read(..., NONBLOCK) == APR_EAGAIN) {
        if (chunking) {
            send data to network
        apr_bucket_read(..., BLOCK);

> Then 5 seconds later, I want to see the rest of the message.  How does making
> content_length_filter "work correctly" make this happen, especially if, as you suggest,
> cannot rely on the FLUSH bucket to be honored by any of the other filters?  Where in
> filter chain does the knowledge get added to flush the filter chain after a non-blocking
> read returns APR_EAGAIN?

We can rely on FLUSH buckets in the connection filters, because 99% of all
connection filters are written by us, and they pretty much have to honor
the FLUSH bucket to work properly.

The psuedo-code above localizes the logic, and it allows it to work for
ANY kind of dynamic request.  There is no reason why this won't work for
mod_perl or PHP requests.  The solution you posted a patch for is very
specific to CGI.

> I completly understand the issue with running this script via a browser that does not
> support chunked encoding. We have the exact same issue in Apache 1.3 and it is well known,
> so just don't go there and save us some time.

Wasn't even thinking about it.  :-)


Ryan Bloom               
Covalent Technologies

View raw message