On Fri, Oct 05, 2001 at 03:39:47PM -0700, Ryan Bloom wrote: > On Friday 05 October 2001 03:34 pm, William A. Rowe, Jr. wrote: > > > Now PLEASE understand that maxbytes 0 (originally, the -1 idea) doesn't > > say 'read everything from this socket' --- it leaves the best-fit for > > the underlying filter to decide. If core wants to give back an even > > number of IP frames, then fine. If SSL wants to give back an even > > number of decoded SSL packets, also fine. It will not mean read until > > EOS, ever. It's up to the underlying filter to decide what is optimal > > for max 0, without allocating a bunch of otherwise useless frame buffers. > > > > And the more that I look at this, the more we need a push-back model, > > because the scope of 'this' filter doesn't live as long as the parent > > filter (with request and connection scopes, respectively.) > > A push-back model is not needed. A filter should not be passing back more > data than the parent can use for this request. If we need to push data back, > then there is a problem. When asks for X bytes of data, it is taking > responsibility for using all X bytes.
I *strongly* agree with Ryan here. Pushback is *not* needed. If filters want to have a read mode of "give me a 'nice' amount", then that is a separate question. (and the HTTP_IN will determine 'nice' based on request boundaries) But if a filter ever says <X> bytes, then f->next *cannot* ever return more than that amount. IMO, we ought to fix mod_ssl and proxy before worrying about optimizing for "return a nice amount". Cheers, -g -- Greg Stein, http://www.lyra.org/
