> 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

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------