Like many people I use Apache's mod_proxy to proxy from *:80 to a bunch of servers running upon 127.0.0.1:XX.
(I've mentioned this too often; but in short I have a bunch of sites all running with thttpd under their own UID).
Why do I use apache soley as a reverse proxy, instead of pound, varnish, nginx, or lighttpd? After all it is pretty heavy-weight. Well the answer to that is that I have a bunch of mod_rewrite rules.
So I'm wondering, could I drop apache if I were to hack together a simple network proxy that would listen upon port 80, reading requests, and directing them to local servers? The answer to that is plainly "yes". There are many reverse-proxies around and writing them isn't hard.
So what would be the point? Imagine a reverse-proxy that understood mod_rewrite rules. That would rock.
In short we'd have to define three things:
- Matching vhost name.
- Destination to proxy to.
- (Optionally) the mod_rewrite rules
Given something like this:
LISTEN 1.2.3.4:80
host example.net or host www.example.net
{
#redirect traffic here
proxy_to 127.0.0.1 1011
RewriteRule /about /cgi-bin/index.cgi
}
When the proxy received an incoming request to http://example.net/about it would actually send the request /cgi-bin/index.cgi to the host 127.0.0.1:1011.
That seems neither too complex nor too impossible.
The hard part would be emulating mod_rewrite 100%. Especially chained requests. I would be willing to write the trivial version, but I suspect the full emulation would be a job of diminishing returns. Am I right?
ObSubject: You crossed the line first, sir. - "The Dark Knight"
Tags: c, proxy, reverse proxy 9 comments