httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Finch <...@dotat.at>
Subject Re: eek. poor chunking behavior.
Date Tue, 12 Sep 2000 01:39:28 GMT
Greg Stein <gstein@lyra.org> wrote:
>
>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.

Think of it as a wart to support the old ap_r* API :-) And it isn't
really a global, just a per-request flag, so the request_rec is the
right place to put it.

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

Hmm, that's a good point. Since the EOS eater is below pass_brigade
it'll have to unset the eos_sent bit in the request_rec. An
alternative is to make it the responsibility of the core to set the
eos_sent flag, which I think might be cleaner.

(For a moment I thought that the EOS might get stuck in the filter
stack such that the core wouldn't see it by the time finalize_request
happens, but this is wrong because the whole point of EOS is to tell
filters to flush out their buffered data.)

Tony.
-- 
en oeccget g mtcaa    f.a.n.finch
v spdlkishrhtewe y    dot@dotat.at
eatp o v eiti i d.    fanf@covalent.net

Mime
View raw message