httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: ssl is broken
Date Wed, 03 Oct 2001 16:15:37 GMT
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


Mime
View raw message