IMO

In the Apache httpd 2.2 development, I've spent a lot of time on the proxy module, especially on the load balancer aspects of mod_proxy. This is an area which interests me and, based on the feedback and popularity of various presentations and webinars I've done, interests others as well. Not that long ago, on the httpd development list, we were discussing ways of enhancing the load balancing mechanism, with possibly a separate process/thread which periodically verifies the health of backend servers and maybe even providing information on their CPU load, stuff like that. With all that in mind, I started working on some additional load balancing (LB) implementations but ran into a snag. See, right before the proxy module runs the actual scheme handler (that is, "what to do with this request"), it calls a special hook: proxy_run_pre_request. The problem is that this hook is implemented as RUN_FIRST/DECLINED, meaning that all functions registered with this hook will run in order until one returns something other than DECLINED. Now this makes sense for a lot of hooks, but really thinking through the proxy module, it doesn't make sense for this one. Adding insult to injury, the one mod_proxy registers is also noted as APR_HOOK_FIRST, making this hook pretty much useless for other modules/submodules to be able to use if you want to also do "other things" at the same time. This is also the same for the proxy_run_post_request as well. So what I proposed was "fixing" these hooks instead be RUN_ALL, allowing other modules/submodules from using them (eg: OK, we've found a balancer, now do some checks against them, or create a timestamp or even bypass that selected balancer all together). Unfortunately, this can be considered an API change, which would make it unsuitable for inclusion in 2.2. In other words, this is easy to address/fix in trunk, but I also want to see this functionality in 2.2.x as well, and a major API change would forbid that. We haven't decided yet, conclusively, if, in fact, it is an API change, or, if it is, how "dangerous" it is (due to the way it's implemented, I'm pretty confident that no one is using it, but that doesn't carry too much weight). So what I'm looking at are adding 2 more hooks: proxy_hook_pre_shandler and proxy_hook_post_shandler, which runs before and after proxy_hook_scheme_handler (that's what the 'shandler' means). This would provide the hook opportunites that I think mod_proxy requires around this stage of processing, as well as being suitable for both trunk and 2.2. The disadvantage is that it adds some cycles to "work around" what is really (IMO), a design/API flaw. The overhead, from all my testing, is pretty much a non-issue, but it still seems an in-elegant solution. But it's likely the one I'll be pushing for...