www-modproxy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: httpd-2.0 nightly build log
Date Mon, 27 Aug 2001 19:02:18 GMT
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" <chuck@topsail.org>
To: <modproxy-dev@apache.org>
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
> 



Mime
View raw message