httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: eek. poor chunking behavior.
Date Tue, 12 Sep 2000 03:27:15 GMT

> 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)

I don't think that argument can be made reasonably for the exact reason
stated below.

> 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.

One of the things we have always said about filtering, is that it must be
possible to write things in a performance aware manner.  If the core has
to be the thing to send the EOS, then we are ignoring the performance
issues.  I would much prefer to traverse the stack one time if at all
possible.  The vast majority of handlers are likely to generate a single
brigade (think CGI, default, file_cache, asis, ...)  To force all of those
requests to go through the filter stack twice is just plain wrong.

> 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.

Huh?  How is this any different than the headers_sent flag that will be
needed at some point, or the assbackwards and headers_only flags that we
already have?  This is information about request processing that is needed
at multiple stages throughout the request.


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message