On Sunday 09 October 2005 18:49, Brian Pane wrote:
> On Oct 9, 2005, at 3:25 AM, Nick Kew wrote:
> > On Sunday 09 October 2005 02:37, [EMAIL PROTECTED] wrote:
> >> URL: http://svn.apache.org/viewcvs?rev=307339&view=rev
> >> Log:
> >> Redesign of request cleanup:
> >> - A new End-Of-Request bucket is pushed through the output filter
> >> chain after the last bucket of the response.
> >> - This bucket gets destroyed by ap_core_output_filter() after the
> >> buckets in front of it have been sent.
> >> - The destroy callback of the EOR bucket invokes the access logger
> >> and frees the request's pool.
> >
> > How do you see this looking from a filter programmer's POV? I can see
> > a danger of some nasty bugs arising from confusion between this and
> > EOS buckets:
> >
> > - Existing filters test for EOS and will ignore EOR. That's
> > presumably
> > fine with you.
> > - Sooner or later, someone will write a filter that propagates EOR
> > and not EOS. Bang!
> >
> > Is there no way you could use EOS directly?
>
> I can think of two easy solutions:
>
> - Wrap the EOR declaration in "#ifdef CORE_PRIVATE," just
> like we do for EOC.
So what does my filter see? A bucket of type <unknown>?
How does this fit with filters of the common form:
loop over buckets {
if (is data) {
read the data;
write something to the next filter;
} else if (is EOS) {
write EOS to next filter;
cleanup and return;
}
/* ignore anything else */
}
If there was an EOR bucket on input, it's lost in the above, yesno?
How do you deal with that? If it doesn't break or break on this logic,
I'm fine with it.
> - Or modify the EOS bucket API to support an optional "on_destroy"
> callback.
Smells of side-effects. EOS buckets get created and destroyed by
intermediate filters - as in my above skeleton.
--
Nick Kew
