Paul Querna wrote:
- Much simpler configuration than mod_proxy, using location blocks
(or locationMatch), rather than ProxyPass' hacking of URI stuff way
earlier.
Proxy is also able to do that. :)
I agree, it is a better way to express the configuration.
Example configuration:
SerfCluster dynamiccluster heartbeat path=logs/hb.dat
SerfCluster statichosts static hosts=140.211.11.130,192.87.106.226
SerfPass cluster://dynamiccluster
SerfPass cluster://statichosts preservehost=0
There are still bugs, and lots of improvements that could be made,
like async streaming of request bodies, from the event thread, but
pretty quickly I think this could turn into a much more powerful
module than mod_proxy, at a fraction of the complication.
Just how much "complication" is hidden inside the serf libraries?
mod_proxy and friends are self contained, and don't use any external
libraries at all. Because of this, the proxy modules are free to
implement any protocol they like (ajp, ftp, connect, fastcgi, over SSL,
etc etc), are free to change the API (within the rules) and use native
httpd concepts like buckets and pools. Can serf do any of this?
The next thought is a more general one. If I was looking at the proxy, I
would want to be far more ambitious in terms of the level of improvement.
Clustering and balancing for example should be possible over any
handler, or perhaps over any location, not just over proxy.
If I was writing proxy again, I would want it to work closer to systems
like dav and svn, where the "source" of the data in a location is specified.
Currently the core has the concept of a "frontend" URL, which is mapped
to a filename, and there is a lot of hack-like stuff in there to support
stuff that isn't a file.
I think a far better idea could be to have a "frontend" URL, which is
provided by the client (we have this already), which is then mapped to a
"backend URL" instead of just a filename (ie, r->filename becomes an URL).
If we have this concept, the need for mod_proxy goes away entirely, and
we just have mod_proxy_http (and friends).
The first part of the handling of any request becomes an exercise in
mapping a frontend URL to a backend URL.
At that point, modules can then step in and handle svn: URLs, or http:
URLs, or just file: URLs, etc.
Does that make any sense?
Regards,
Graham
--
smime.p7s
Description: S/MIME Cryptographic Signature
