From: "Justin Erenkrantz" <[EMAIL PROTECTED]> Sent: Wednesday, October 03, 2001 11:15 AM
> On Wed, Oct 03, 2001 at 08:10:11AM -0500, William A. Rowe, Jr. wrote: > > Now ... the core input filter can't decide where to break input, it has to allow > > connection filters to insert themselves and decode whatever is read. > > > > That means that the core filter needs to be split, and another line input > > dequeue filter needs to be inserted as the last 'connection' filter. That > > leaves us ready for the request filter to read 'lines' or 'bytes' and make > > decisions based on the lines and bytes read, and fall back on the line input > > dequeue to keep the 'next' request's input set-aside for the next request. > > Yes and no. You are kind of right here - I see why you might want to > do that, but that was the previous architecture with HTTP_IN and > CORE_IN. (HTTP_IN was an admittedly bad name for it, but that is > what it tried to do - do readlines.) Then that was the change, to eliminate the HTTP_IN filter? Removing HTTP_IN and trying to have a CORE_IN of the everything and the bathwater is a broken model. You've succeeded in reverting Apache to an http-only server, if that was your intention. As this eliminates our flexibile interoperability for other protocols, I need to veto this patch. > A lot of the complexity was removed by assuming that only one filter > has the -1 brigade. And, Greg and Ryan have commented that they > would rather see CORE_IN not deal with socket buckets at all but > read directly from the socket. The CORE_IN filter reads directly from the socket. If you want to provide a readline and readbytes here, both blocking and nonblocking, that's fine. It doesn't mitigate the fact that the ssl filter will transform any readline into read bytes, and that an HTTP filter must handle readline after recieving some readbytes, and handle ALL the chunking behavior. > Ryan and Greg, how do you guys see this working? I yield to > your wisdom here... If the CORE_IN read from the socket > directly as you both have suggested, how would (or should) > mod_ssl interact? > > I see it being a much simpler task to write a module that > replaces CORE_IN than trying to work around it. It's not > that much code - and I think mod_ssl could even ditch > some of the lesser-supported modes (readbytes==-1 and PEEK > which it already doesn't support). We'll probably end up > removing them in core at some point. -- justin If you have to replace CORE_IN, then your implementation of CORE_IN is broken. For that too I would veto the patch you've committed, if this can't be fixed to allow the old functionality. 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. Bill
