From: "Greg Stein" <[EMAIL PROTECTED]> Sent: Wednesday, October 03, 2001 12:33 AM
> On Tue, Oct 02, 2001 at 08:34:30PM -0500, William A. Rowe, Jr. wrote: > > From: "Justin Erenkrantz" <[EMAIL PROTECTED]> > > Sent: Tuesday, October 02, 2001 8:29 PM > > > > > On Tue, Oct 02, 2001 at 01:24:25PM -0700, Doug MacEachern wrote: > > > > with current cvs all httpd-test ssl tests hang, stacktrace is same for > > > > all... > > > > > > I bet it's related to the input filtering changes. > > > > > > I have no clue how the whole mod_ssl input filtering works, but I'll > > > try to take a look. My guess is that mod_ssl is just a big quagmire. > > > > That, or your input filtering changes were the big quagmire. Either way, > > that sure sounds like the interaction that broke ssl. > > I'll lay good odds that it is in mod_ssl rather than the input filtering > changes. Even *if* it is the latter, at least we have a codebase that is > much more maintainable now. If that statement was harsh, I'm sorry, and yes - legibility and maintainability is important. That said... We have only one extensive use of Input Filters in the httpd tree at this time, and that's mod_ssl. That this wasn't even tested sort of surprizes me. 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. Bill
