I have only one concern. Right now we have Apache 2.0 - which aims to be an HTTP/1.1 reference implementation. Today that RFC includes all of the Proxy functionality.
One thing I forsee (possibly) happening is a splintering of HTTP v.s. HTTP-PROXY v.s. HTTPS v.s. HTTPS over HTTP. You get my thought. If we will want to continue to support Apache 2.0/Proxy 2.0, while building the next generation of proxy protocol support, I'd suggest where mod_proxy lives today is the ideal location. We could begin implementation of future features, independent of the HTTP/1.1 specification. If anyone disagrees, please be vocal. I'm 100% up on tight integration between _ALL_ of the subprojects (and will make it so on Win32), but I'd like to know Proxy can continue to evolve in a module-2.1 branch while still supporting the current implementation. Does that make sense? Bill ----- Original Message ----- From: "Chuck Murcko" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 27, 2001 1:31 PM Subject: Re: httpd-2.0 nightly build log > IIRC we voted +1 to reintegrate mod_proxy twice on new-httpd, and I > think mod_proxy was more stable 9 days ago at 2.0.24 than at the time of > either vote, so I'd dare to consider that a mandate. 8^) We discussed > alternative packaging (a rollup release) for httpd, but not much has > come of that idea yet. > > So it's my intent to fold the proxy back in before httpd release, unless > there's a compelling reason not to. For now, we'll go ahead to cut > milestone releases starting with the 2.0.24 tag. I wouldn't even call > them beta, as that connotes remaining a separate project or release to > me. They'll still have version numbers, though. > > Like mid air refueling, merging proxy back into httpd will work best > when both moving pieces are in sync; that's the tricky part. > > If you or other folks think this is a nonoptimal way to proceed, let's > discuss it further. I could be way off base here. Plus I don't always > communicate what I think well (this sentence might just prove itself). > > Chuck >
