httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: How I Think Filters Should Work
Date Wed, 15 May 2002 23:04:09 GMT
On Thu, May 09, 2002 at 05:57:16PM -0700, Justin Erenkrantz wrote:
> I really think you're talking about a push-based filter system.
> However, it seems that there was a conscious decision to use
> pull for input-filters.  I wasn't around when that discussion
> was made.  I'd like to hear the rationale for using pull for
> input filters.

Historical. Handlers "pull" input data. Thus, the input filter stack also
needed to be a pull mechanism.

In apr-serf, I've advocated providing both models to the application. The
app can push content at the network, or the network can pull content from
the app. Also, the app can pull input from the network, or the network can
push input at the app.

Note that a push-based filter stack can be used in a pull-fashion. When the
app wants to pull content, the subsystem tells the network endpoint to push
data into the filter stack. The data is then captured on the other side, and
an appropriate amount is returned to the app (and the rest is buffered off
to the side.

> Sending metadata down is a big change.  Again, I *think* this was
> discussed before, but was determined that this wasn't the right way.

No. We think it is right, but it was too big of a change for Apache. Too
much code simply likes to write to r->output_headers.

> (If we do this for input filters, I think we need to do the
> same for output filters.)

The filter stack "should" transport all metadata. The request_rec is an
out-of-band data delivery that hurts us quite a bit in a filter-stack world.

> > around in my head for a long time. When they become clear enough I will
> > write up a more formal and concise proposal on how I think the future
> > filter system should work (possible for 2.1 or beyond). I think the
> > apr-serf project is a perfect place to play with some of these ideas. I
> > would appreciate any constructive comments to the above. ]

I would totally agree. My hope is that apr-serf can establish a new
substrate for the filter systems. It is only a client, though, so it would
be used by proxy, but not by the MPM/listener stuff in Apache (the filter
stack code would be; just not the standard HTTP client endpoints).

> I'm not sure I'm happy that so early in the 2.0 series that we're
> already concerned about the input filtering.  I don't think it's
> ever been "right" - probably because it was ignored for so long.
> It's showing now.  If this prevents people from writing good
> input filters, I think we need to fix this sooner rather than
> later.  -- justin

The input stuff works, but it could probably be better. At a minimum, it
probably makes some sense to have a mode that says "give me as much of the
request as you feel cozy giving me." That would allow the input filters to
return a SOCKET rather than a bunch of 8k buckets. However, to really make
it work (at all, and "best"), we would need a variant of the SOCKET bucket.
It would allow us to share the apr_socket_t and apply a read-limit on the
thing. Thus, you could say "here are 1000 bytes, read from a socket." That
would give you delayed read from the socket (and possible later optimization
of doing a sendfile() from the socket fd into a file fd), yet apply the
appropriate request-boundary limitations.


Greg Stein,

View raw message