Brad I'm plus 1, especially if we can cause libwww to instigate this connection mode for httpd-test and prove that it behaves per the RFC convention.
But I have a better proposal - let us simply move back the entire mod_ssl 2.1 back to 2.0. Only binary compat issues would need review. But too many good things have happened on 2.1 to this specific component. I'll propose SSL-C and win32 build solutions I've adopted for Covalent's build farm, over the next few days into 2.1. note that the 2.1 rewrite of the autoconf .m4 stuff made thins much worse - I use a simple hack on top of the 2.0 build scripts. When we declare 2.1 baked, we should shift that module back :) My QA folks have done extensive work wrt 2.1 (up to the last two weeks of rapid patches) and have found it very well suited to build under 2.0.48, compared to the 2.0 flavor. Bill At 10:08 PM 3/4/2004, Brad Nicholes wrote: > I would like to resurrect an old discussion. About a year and half >ago rbb and wrowe committed a patch for mod_ssl to provide the SSLEngine >upgrade capability. It seems that one of the reasons for not back >porting it to the 2.0 tree was because there weren't really any clients >that supported it. Well I know of at least one now which is Novell's >iPrint client and I suspect that there may be others out there. Does >anyone see any major issues with backporting this functionality to 2.0? >If not then I would like to propose it for back port and see if we can >get it done. The attached patch can be applied to the 2.0 branch. HEAD >already contains all of the patches. Here >(http://www.apache.org/~bnicholes/wget_tls_prelim-1.8.2.tar.gz)is a >hacked version of wget that is able to test the functionality. Invoke >wget with the -u parameter to allow it to request the TLS/SSL upgraded >connection. > >Brad > > > >At 11:46 AM 10/15/2002, [EMAIL PROTECTED] wrote: >[snip] >>The second is SSL upgrade. I have the patches, they haven't been >>committed yet. I have attached them at the bottom of this message. >The >>reason they haven't been committed, is that I don't have a client to >test >>them with, and I haven't had time to create one. The responses are >>correct I have checked them in plain text. The place that bugs most >>likely exist, is the actual upgrade code that does the handshake. >This is >>an important feature, and I would really like to see it in 2.0. > >I see a couple of very important aspects to this patch: > >1) we must have an implementation of connection: upgrade for libwww, >since > that is the mechanism we use for httpd-test/perl-framework. I don't >have > such a fix, so I'm just asking the community if anyone has explored >that > avenue. > >2) it has to be maintained. I've looked at this patch, it appears >quite correct. > I'm going to begin working on applying it to cvs HEAD. I'm not >concerned > about it quickly appearing in 2.0 since there are no clients right >now. I'm > much more concerned about it's availability once clients can support >it. > >3) right now, the ssl code (ssl_engine_io) was already pretty heavily >refactored. > The patch wasn't easy to apply. We are discussing other >refactorings that > will make SSL much simpler to follow and far less error-prone. >Those will > effectively invalidate the effort Ryan has already invested. > >My proposed solution is to review the patch and apply it to cvs HEAD. >Get it >committed. Of course there are no test suites right now, and there >won't be >for a little while yet. But once the code exists, it will be simpler >to keep the >SSL upgrade facility maintained, and debug it as the clients become >available >(most especially, libwww exercises through perl-framework.) > >Any disagreement? > >The current patch that applies to cvs HEAD is attached. > >Bill > > >Brad Nicholes >Senior Software Engineer >Novell, Inc., the leading provider of Net business solutions >http://www.novell.com
