httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: filtered I/O - flow control
Date Thu, 01 Jun 2000 18:35:15 GMT

A couple of things that MUST be done regardless of which design is
used.  The headers can't be sent from the output generator.  If they are,
the filter's must parse and munge HTTP headers, Bad mojo.  The headers
should be stored in an array in the request_rec, and sent out from ap_r*
after the filters are run (in the hook design) or from ap_lfoo just before
the data is sent (in the link design).

The basic flow control for the hook based design would be that 

The generator would generate the data and pass it to ap_r* which passes it
to the first filter.  The first filter passes it back to ap_r* which
passes it to the next filter and so until all filters are done
executing.  At that point, it gets passed to ap_bwrite which actually
writes to the network.  If at any point there is too much data to write to
the network, it will be up to Apache's internal buffering to catch it and
hold it until the socket is ready.  I expect that this is the way the link
based design would work as well.  In this design, there is no reason for
the filters to "wake up" once the socket is ready for more data, because
they weren't executing when the data was being written to the socket.

It will need to be possible for either approach for the filter to save the
data off to the side (along with the current filter list [either as a
linked list or as a table (the way hooks are implemented)]), and then come
back later and get the data back and continue parsing it.  Both
implementations have mechanisms for doing this in their design.


On Thu, 1 Jun 2000, Greg Ames wrote:

> How would flow control work with each of the proposed filter designs?
> Suppose we have I want to use a mod_include filter to put a header and
> trailer around the new-httpd mail archives for April, use mod_php to
> filter out junk from the mail headers, then put it on the wire.  The
> socket isn't likely to swallow all of that data in one gulp.  So how do
> the filters wake up once the socket is ready to write again, and where
> does the data sit in the mean time?
> Greg Ames

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

View raw message