mod_proxy_core and backends
Since version 1.5.0, the dynamic page processing interface core functionality was consolidated into mod_proxy_core and only the differences between the interfaces moved into a backend for each. This reduces duplication, with some obvious benefits. Less duplicated code implies less stuff in memory, less chances for errors, more testing for the core, and optimizations apply to all interfaces.
The syntax has changed a little, for example, we no longer assign path prefixes to configurations, but use selectors to reduce the reach of the backends.
Suppose that we want to use mod_proxy_core, we add it to server_modules along with the backends we want. Then we carve out a niche for each backend and configure the backends. For example, to use SCGI for a python application and FastCGI for PHP, we write:
server.modules = ( ...,
"mod_proxy_core",
"mod_proxy_backend_fastcgi",
"mod_proxy_backend_scgi", # see appendix B for all backends.
... )
$HTTP["url"] =~ ".py" { # use SCGI for python files
proxy_core.protocol = "scgi"
proxy-core.balancer = "carp" # tries to keep processes together
proxy-core.backends = { # we have 3 SCGI servers to balance:
"127.0.0.1:3456", # a local port (by IP address)
"otherhost.mydomain.net:3456", # a port on another host
"unix:/tmp/python.socket" # a unix socket
}
proxy-core.max-pool-size = 3 # for SCGI the number of backends
# for other options, see Appendix B
}
$HTTP["url"] =~ ".php" { # use FastCGI for PHP files
proxy_core.protocol = "fastcgi"
proxy-core.balancer = "sqf" # tries to balance workload fairly
proxy-core.backends = {
"unix:/tmp/php-fastcgi.socket",
"[::1]:4001" # on IPv6 host 1 in this network, port 4001
}
proxy-core.max-keep-alive-requests = 8
# analog to server.max-keep-alive-requests, see chapter 9
proxy-core.allow-x-sendfile = "enable" # see chapter 9
}
The use of selectors gives us greater freedom on when to use which backend, and the uniform syntax makes it easy to learn and use.