Unicorn is a Rack HTTP server for Unix, fast clients and nothing else
Socket handling bugfixes and socket-related usability and
performance tweaks. We no longer trust FD_CLOEXEC to be
inherited across accept(); thanks to Paul Sponagl for diagnosing
this issue on OSX. There are also minor tweaks backported from
0.9.0 to make non-graceful restarts/upgrades go more smoothly.
The 0.9.x series (including 0.9.1) is NOT recommended for
production use, try 0.8.2 instead.
Unicorn is a Rack HTTP server for Unix, fast clients and nothing else
So who exactly would benefit most from this library? What is the target
audience? Just wondering more background on it.
The target audience is people deploying/maintaining/managing HTTP apps
that only clients within their LAN are expected/allowed to hit. Of
course, with a decent reverse proxy in front, all traffic from the
reverse proxy can be considered internal and fast (unless your LAN is
horrible).
Clients don’t have to be on a Unix-like OS, of course.
It’s also a testing ground for features that may make it into Mongrel 2
(assuming portability requirements are met). Unicorn gives us more
freedom to exploit features unique to Unix-like systems (and maybe even
(optionally) Linux 2.6+ in the future).
Fwiw, I’ve known about (and implemented similar (but meaner :)) things
like the recently-disclosed Slowloris for several years now. That’s why
we refuse to support Unicorn talking directly to the Internet at large.
There’s also some philosophy and design notes here that describe why we
did some of the things we did: