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.) 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. 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
