nginx compiles quickly enough that a script for "service nginx reload" could recompile and replace the binary, and it will only be a little slower than "service apache reload" will be.
It's like a sausage, you can enjoy eating it without seeing how it's made.
I don't think any other popular http server support this. If there's a web server written in Erlang, you can be sure that is available (it's a core Erlang feature).
But apache can let you load a new .so without recompiling (or even restarting) the main server, which, for most intents and purposes, gives you equivalent functionality.
I think this sub-thread may be missing the point that on a production server you may not have installed the whole toolchain required to re-compile your webserver so dynamic module support is actually kind of a bigger deal than you might think.
Well, the idea solution is that you don't compile things directly on your web server. There's no reason you can't compile it on a workstation and package it for deployment to production. Consider what you would be doing if you had a cluster of web servers. Would you compile manually on each server, or create a package (rpm/deb/tgz/etc) and deploy?
No. But as I pointed out above, Apache comes with 67 modules out-of-the box on Debian, which means you're much less likely to need a custom package, as opposed to the (relative) hassle with nginx. This is why I very much look forward to seeing nginx with reloadable modules.
Well, the point is, Apache comes with enough modules that I never had any need to actually go and compile a custom one. And since they can be loaded at runtime, in terms of memory you only pay for what you use.
I haven't used nginx often, but the default Debian nginx doesn't come with many things included, I find.
[I'm a huge nginx fan myself but recall that this is coming to the main project soonish.]