> Maybe filtering needs some pushback so each higher level filter can avoid > hanging on to bytes it doesn't want or need, and push them back at a lower > level filter that can keep them in their queue for the next transaction > within the request or the next request within the connection.
Yes, as we discussed several times before, the only thing that the filter closest to the socket (CORE_IN or whatever else you might call it) can do is read large blocks of data from the network and place them in a buffer with a connection lifetime. In other words, what BUFF did. The only way filters can improve on that is by passing brigades and allowing the downstream filter to "unread" (pass back to the CORE_IN) any data that is beyond its application frame (message boundary). OTOH, the notion of replacing CORE_IN based on the notion of the connection is really no different than the IOL code that Dean introduced. There are reasons why we don't want to do that, but nobody bothered to document them. I think we have to get off the notion that recent modifications have broken mod_ssl -- it has yet to work correctly with filters. Any module that makes implementation assumptions about the implementation of the upstream filter, or the nature of the data being passed through the filter, is broken, and I personally think that includes every implementation of filters in httpd. That is why we have a showstopper item about rethinking the input filters. In any case, this part of httpd-2.0 is not ready for prime time. It desperately needs our unfettered attention, which means not approaching every change as if it were a life-or-death situation. Just fix it. ....Roy
