On Fri, Oct 05, 2001 at 05:34:41PM -0500, William A. Rowe, Jr. wrote: > Aaron and I were chatting about this in stream-of-consiouness mode, > let me boil down our collective lightbulb.
The more, the merrier. =) If you could pass a few lightbulbs down here, I'd appreciate it... > We actually have two number; > > * minimum required bytes (blocking) to return > [could be 0 - don't care] Wouldn't this lead to returning more than you may be able to handle? How I see it is that you provide the maximum number of bytes you are willing to accept. > * maximum bytes (non-blocking) that can be accepted > [could be 0 - no limit] Yup. But, I think there are reasons that we shouldn't be using 0. What would be a case? (Do you mean this as two length parameters given to ap_get_brigade? What about bogus values - 0,0?) > 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. This would be a real good time to change *readbytes == 0 to be a specific mode rather than an implicit "give me a LF line." =) The question is when do we stop? I'm about to commit a patch (feel free to revert) that will make blocking reads only do one socket read and return at most *readbytes. I would say that maxbytes 0 should be "one socket read" - are there any other alternatives here? (And, I'd say this is only valid connection<->connection filters since request filters shouldn't be reading indeterminately like this.) > 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.) The reasoning that I would say that we don't need a push-back model is that we can't remove a connection input-filter once it has been inserted. Also, you should not be returning more data than is asked for. Less than what you ask for should be fine. There are also safeguards that should prevent the request scope from reading too much - HTTP_IN should ensure that we *never* read past the end of the request - it should be the bridge between request and connection scopes - it buffers no data. And, we shouldn't worry about connection filters *unless* we want to be able to remove them mid-stream. And, I think that will get awfully complicated. I believe at one point Roy may have mentioned that all filters should be in the chain at all times. If they are interested, they intercept the data and handle it. If at some point they are told to ignore the request, they can just pass along any buffered data that they may have previously read. Would that resolve the push-back concern? Was there an implementation detail that prevented this from working? -- justin
