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. Cheers, -g -- Greg Stein, http://www.lyra.org/
