httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: eek. poor chunking behavior.
Date Tue, 12 Sep 2000 00:59:51 GMT
On Mon, Sep 11, 2000 at 05:34:24PM -0700, rbb@covalent.net wrote:
> On Mon, 11 Sep 2000, Tony Finch wrote:
> > There's a problem with EOS in this scheme; to make things optimal in
> > the normal case there will be just one trip through the filter stack
> > with a brigade consisting of two buckets (a FILE and EOS, or a PIPE
> > and EOS...). If the handler is using ap_r* then it won't send an EOS
> > (and there may be some buffered data lurking) so it'll have to be sent
> > by ap_finalize_request.
> 
> I am attaching a patch to fix EOS.  This basically adds an int to the
> request_rec.  This int checks to see if the EOS bucket has already been
> sent.  The int is initiall set to zero.  Ap_pass_brigade checks the last
> bucket everytime it is called.  If the last bucket is an EOS bucket, then
> the flag is set.  If not, it isn't.  This assumes that EOS will not be any
> buckets after the EOS.  Since it doesn't make any sense to add a bucket
> after the EOS bucket, I am ok with that.  ap_finalize_request checks that
> flag before it sends an EOS bucket down.  This patch is completely
> untested, but it makes logical sense.  It should fix the bug with the cgi
> modules, namely that two EOS buckets get sent for every CGI request.

Well, you could argue that the CGI module shouldn't be sending an EOS
bucket... that the core will send that when the handler returns.
(specifically, it will be sent by finalize_request)

That said, I think it would be preferable to *allow* a handler to send an
EOS bucket so that we can have a single brigade during the content
processing. By definition, finalize_request's posting of an EOS implies at
least two brigades through the filter stack.

I feel a bit "ooky" about this patch (specifically, dropping what amounts to
a global into the request_rec), but I don't believe there is a better
approach.

NOTE: your change to ap_pass_brigade() should move the check inside of the
"if (next)" since you deref "next".


Somewhat separate: we have been discussin an "EOS eater" filter that a
subrequest would insert into its chain. I'm presuming that it has no
interactions with this patch, but am mentioning it in case somebody else
sees it. ??

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message