httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: cvs commit: httpd-2.0/server core.c
Date Tue, 16 Oct 2001 14:46:14 GMT
> rbb         01/10/15 22:18:39
> 
>   Modified:    .        CHANGES configure.in
>                modules/proxy mod_proxy.h proxy_util.c
>                server   core.c
>   Log:
>   Cleanup the proxy code that creates a request to the origin
>   server.  This change adds an optional hook, which allows modules
>   to gain control while the request is created if the proxy module
>   is loaded.  The purpose of this hook is to allow modules to add
>   input and/or output filters to the request to the origin.  While
>   I was at it, I made the core use this hook, so that proxy request
>   creation uses some of the code from the core.  This can still be
>   greatly improved, but this is a good start.

Why on earth was a dependency on mod_proxy.h introduced to core.c?

This really defies good abstration, so I'd argue the logic is broken.
There is no reason to bind this here, put all the bindings in proxy
and let core leave them alone.

Either this is a core hook, or it is a proxy hook that core shouldn't
be dancing with.  I've been trying to untangle the proxy request from 
core, and now we introduce new confusion?

Sorry if I'm just being dense, but could you explain what core is
doing in this mix?

One major aspect of this entire 2.0 schema is _not_ requiring core
changes to add modules (e.g. Proxy).  If we fall back on that old
habit, we will end up back in the EAPI scenario.  Perhaps this isn't
a proxy filter, but something that can be defined more broadly for
other purposes?

Bill




Mime
View raw message