"Ryan Bloom" <[EMAIL PROTECTED]> writes:
> > From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251-
> >
> > Initially I would think that a filter should see at most one EOS.
> > mod_ext_filter doesn't have logic to ignore subsequent ones, resulting
> > in a superfluous error message from a failed syscall when it tries to
> > re-do some cleanup when it hits a second EOS.
> >
> > In this case, the subrequest is handled by default_handler which
> > passes down a FILE bucket and an EOS bucket. After that has
> > completed, ap_finalize_sub_req_protocol() passes down another EOS
> > bucket. Why does ap_finalize_sub_req_protocol() pass down an EOS?
> > Isn't the handler responsible for that? Is this to clean up in case
> > the handler encountered an error and failed to pass down an EOS?
>
> Output filters can only support and expect a single EOS bucket. Input
> filters, however, seem to be moving to a multi-EOS model.
okay so far
> Ap_finalize_sub_req_protocol sends down an EOS bucket just like
> ap_finalize_request does. That means that it is only sent if the
> handler didn't send it.
I suspect you're talking about this line of code which doesn't exist
in CVS:
Index: server/protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/server/protocol.c,v
retrieving revision 1.105
diff -u -r1.105 protocol.c
--- server/protocol.c 7 Jun 2002 22:31:34 -0000 1.105
+++ server/protocol.c 10 Jun 2002 18:33:54 -0000
@@ -1033,7 +1033,10 @@
void ap_finalize_sub_req_protocol(request_rec *sub)
{
- end_output_stream(sub);
+ /* tell the filter chain there is no more content coming */
+ if (!sub->eos_sent) {
+ end_output_stream(sub);
+ }
}
/* finalize_request_protocol is called at completion of sending the
Is that what you expected was there? (the PR 9644 scenario is fine
with this patch; I'm poking around now to see if we used to have this
check and removed it for some reason)
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
