I think everything Ryan has suggested is goodness, but we still have a conundrum....
proxy_http must call ap_run_pre_connection() to install CORE_IN/CORE_OUT (and set up the core_net_rec). However, we really should not call ap_run_pre_connection() because it's not valid for all the loaded modules to install their default front end filters into the backend connection. A couple of solutions: 1. Each module becomes aware of how their hook is being used, to install front-end or back-end filters (Yech). 2. We need to architect a new hook in Apache to give modules the opportunity to install backend filters, maybe named ap_run_proxy_install_filters() or something like that. Most modules will not use it (obviously mod_proxy would). core.c would need to implement the hook to install default in/out filters (CORE_IN/CORE). Thoughts? Bill > > Ryan Bloom wrote: > > > > > > The challenge of course is to tell a filter (like mod_headers for > > > > example) that "this config is for the normal stack, and this > second > > > > config is for the backend stack". > > > > > > That is easy to do. If you create the ProxyAddFooFilter > directives, > > > that directive adds the filter to the correct filter list, and the > > > filter just does the right thing. > > > > If you add the mod_header filter using ProxyAddInputFilter, and you > > issue the command: > > > > Header set X-Test blah > > > > How does mod_headers know whether the above directive applies to the > > frontend normal filter chain, or the backend one? > > > > I imagine the current behavior will be that mod_headers will be run > > twice - once on the front, once on the back. > > You re-write the proxy code so that ProxyPass can be put inside of a > <Proxy> block. Then, you only specify the individual headers for each > block. > > Ryan > >
