httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <>
Subject Re: 1.1b3 and things???
Date Thu, 06 Jun 1996 19:53:34 GMT
David Robinson liltingly intones:
> On Thu, 6 Jun 1996, Chuck Murcko wrote:
> >...
> > I've got another round of patches for the proxy module, and I'm trying
> > to get all the advertised features working in all environments, as
> > well as some bugs fixed, before moving on to caching strategy and
> > protocol semantics issues (as well as moving towards a kinder, gentler,
> > more 1.1ish operation).
> > 
Um, I meant HTTP 1.1ish, there.

> > Mod_proxy.c is just too darned big, though. Any objections to splitting
> > it into several pieces soon? It's possible it may be easier to put
> > this into the distribution in its own subdirectory. Pieces I can see
> > as logical chunks are:
> > 
> > mod_proxy_ftp.c
> > mod_proxy_ssl.c
> > mod_proxy_http.c
> > mod_proxy_<other protocol here>.c
> > mod_proxy_cache.c
> > mod_proxy_util.c - some of this might move to util.c later
> > mod_proxy.c
> > mod_proxy.h
> > 
> > It could be built as a library, thus the Configuration line
> > 
> > Module proxy_module       libmod_proxy.a
> > 
> > instead of a long list of objects.
> With respect, too big for what?
It's 3230 lines of relatively dense code. Those aren't all executable, but
anything over about 600 lines gives me an uncomfortable feeling. It's more
than twice the size of any other piece of Apache source code (Even 1500
lines is a tad too big, IMHO). Isn't it really a subsystem at this point?

> You can see that it was written with this sort of split in mind. However,
> what I intended was that it would be split into
> mod_cache.c
> and
> mod_proxy_<proto>.c
> The primary reason for introducing buff.c was to facilitate mod_cache.c.
> Once this is done, proxy modules would contain only the proxying code,
> and would be attached to the server using the standard API.
I was suggesting splitting up the code into related C modules, to build
more easily. No APIs(yet, other than the function args and usual config
command stuff), no connection abstractions(yet), just something easier
to maintain and faster to build when testing and extending.

I'm not convinced that the proxy idea works better with each protocol's
proxy glued to the top level API. This approach would seem to force
per-protocol caching, and I don't see an advantage to that, given that
background cache garbage collection (or a separate daemon) would be
a really nice feature for proxy performance. On the other hand, there's
only one API.

Right now, I'm simply trying to make sure all current features work
reasonably correctly for inclusion in 1.1 release. Any changes of this
sort wouldn't occur until 1.2, anyway.

> BTW, why does the latest mod_proxy.c have an unused hook for SSL?
> Either SSL should be included, or there should be no hooks.
SSL's going in next checkin. Hopefully, so is PASV ftp.
Then the proxy is also fully functional through SOCKS proxies and
tightly configured screening routers, and the like.

David, should I infer from your reply that you have time now to work on
Apache stuff again? If so, please feel free to. I'm neither looking to
usurp your role here, nor denigrate the considerable quality work you
have put into mod_proxy, among other things. I've collected a list of
about 16 items suggested by the group to turn this module into a high
capacity, industrial strength proxy. That's where I was headed in your
absence. I've 5-6 items to go to get there, but not until 1.2.

Chuck Murcko	N2K Inc.	Wayne PA
And now, on a lighter note:
The easiest way to figure the cost of living is to take your income and
add ten percent.

View raw message