As far as I know there are:

squid -- does caching
pound -- does SSL
plb -- event based (what else?)
mod_proxy -- de facto standard, but kinda sucks
perlbal -- includes the kitchen sink, but no caching

But an unbiased review? Not that I'm aware of.

out of interest, what sucks about mod_proxy? people sometimes suggest we use it instead of squid...

-- heavy(ier than alternatives)

-- exposes backend connect errors to clients, rather than reconnecting to another node, but see:

-- can't connect to more than one backend node, so it isn't really a load balancer, just a tiny little buffer. you can make it connect to multiple backend nodes with mod_rewrite + external rewrite map program grossness, but then it gets slow, and see second item above.... no way to handle errors if you map to a down node.

-- no visibility into what's going on, so hard to plug into monitoring tools (compare with all perlbal's runtime introspection commands)

-- not enough buffering flexibility

Perlbal is way better than mod_proxy. I'm even using it for reverse proxing doc.php.net as well as various other sites. You definately won't regret switching to Perlbal ;)

We love us some squid at work; we have this ugly LVS<->Squid<->Apache<->Filer abomination for our www.${work}.org cluster, and it works great. We get appreciable winnage out of using squid for local caching of hot files.

But, sadly, squid for Host:-based vhosting had issues when a coworker looked into it last. My understanding is that it's been progressing, but I'm not sure where it stands.

Hi Brad,

Do you have a example config where you've setup the certificate and key for doing SSL support? :)

Docs and example confs are in the latest 1.35 release.

Excellent sir!

I have used Pen (http://siag.nu/pen/) in the past and it has worked. What was especially convenient for me was the fact that Pen runs on Windows too, unlike most of these suggestions above. And I am doomed to use Windows servers.

How is monobal coming?

Monobal turned into Perlbal.

Perlbal should run on Windows, too, especially with PAR.