> > > > 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.
> >
> > 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
ap_fflush
}
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, we
> cannot rely on the FLUSH bucket to be honored by any of the other filters? Where in
>the
> 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
_____________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
Covalent Technologies [EMAIL PROTECTED]
-----------------------------------------------------------------------------
