Neutral:

* You are probably not Google and the http/https server is almost certainly not a performance problem worth worrying about.

Pro-Apache:

* Swiss army knife. At my day job we use a pile of Apache modules; if we went nginx we'd have to replace these with a kitchen drawer full of standalone gadgets.

* You know Apache well.

* Lots of LAMP apps pretty much presume Apache (WordPress plugins in particular) and nginx support is a me-too.

Pro-nginx:

* Smaller and cleaner config.

* You know nginx well.

* nginx support is getting better, if you like nginx it's worth checking your prospective application.

Honestly, for almost all use cases it probably doesn't matter which. Pick whatever makes you most effective.

One point against nginx: it's an "open core" product. The free/OSS version lacks features so that Nginx Inc. can sell them to companies.

Which includes super fun stuff like if you're proxying to a back end by name it only resolves the IP on either start-up or first connection (not sure which), unless you specifically add a static DNS resolver IP address and do some variable stuff. When your upstream DNS resolver stuff could change, that tends to mean you need to install DNSMasq and similar locally and point your nginx to it.

Fixed in Plus, not in the open source product.

So nobody's fixed this in a fork?

Supporting a fork, or even a patch set, is a lot of work. Especially if you know full well that it's never going to be accepted upstream.

And unless you support it solidly and long-term, nobody would really use it: paid support from Ngnix is much less risk.

There's the tengine fork: http://tengine.taobao.org/ https://github.com/alibaba/tengine

It's 99% of the same. Green apple and red apple.

If you have an existing configuration written in any, it invariably ended up as a pile of hacks, domains and misredirections that is a pain to rewrite for the other. That makes it hard to change.

Apache has support for some modules, mostly for authentication, that nginx doesn't have.

Old applications, like wordpress, are only supported and documented on Apache.

> Old applications, like wordpress, are only supported and documented on Apache.

Wordpress is not old, it is just very badly written.

>Old applications, like wordpress, are only supported and documented on Apache.

Not true: https://codex.wordpress.org/Nginx

> This page is marked as incomplete. You can help Codex by expanding it.

I've been using WordPress on Nginx for almost a decade now, I just found that bit funny given the context.

> Old applications, like wordpress, are only supported and documented on Apache.

WordPress itself is fine. Many plugins, however, assume Apache (and MySQL).

Well, the best pitch I've heard for nginx is:

"Come for the performance, stay for the configuration".

The Nginx configuration format is a lot more coherent than the Apache httpd equivalent.

One of my favorite features of Apache is MultiViews. It lets me make a file like this:

    www.example.com/widgets.html

and this address without the file extension will work:

    www.example.com/widgets

If the file is widgets.php or some other language that Apache considers a script, then even this will work:

    www.example.com/widgets/1234

and $_SERVER['PATH_INFO'] will be set to /1234.

This is all turned on with one line in a configuration file:

    Options +MultiViews

instead of having to turn on mod_rewrite, with its complexity.

I find nginx easier to use and their documentation better. On the other hand Apache has some features which are missing from nginx like supporting client certificate authentication only on a specific path. Either will probably solve your use case just fine.

Apache is stable, rarely any security related issues; and even then, it's usually a module not installed/enabled by default.

Nginx and Apache are about the same performance, assuming you are on 2.4.x and using the latest apr/apr-util/apr-iconv. The memory footprint is about the same and benchmarks are about the same.

Nginx still hard codes libc options that I have to undo in the Makefile each time to get the glibc hardening options enabled. (PIE, Full RELRO, stack protector and so on) I have not tested the last 3 or so releases, so maybe Maxim has resolved this?

I prefer Apache for anything CGI related, as the security is more tightly coupled to the webserver. With NGINX, I have to use another daemon that has it's own security settings, environment, etc.

One difference that I think is important: no .htaccess in nginx. So the only way to change any configuration in nginx is in the configuration files and a server restart is necessary.

Note that this is intended and desirable for any server with moderate to high loads. Plus, Nginx can reload its configuration gracefully without dropping connections.

For the uninformed: The reason .htaccess is not desirable is that the server has to check each directory in the request path for an .htaccess file and read its content.

What's the actual effect of this? Negative filesystem lookups are cached, and I believe they're cached forever on local filesystems (since you know if anyone's writing to the local filesystem), so the overhead is just that of a couple of syscalls. That feels like it's small enough that you really want to benchmark to see if it matters for you.

No effect, on my server, a $5-per-month Digital Ocean droplet. Using the program called Apache Bench (ab) to retrieve a file four directories deep: /a/b/c/d/e.html

With .htaccess files turned off (AllowOverride None), I got 282 requests per second. With .htacess files on (AllowOverride All) I got 286 requests per second (Yes, actually a few more hits per second with .htaccess turned on, but the results swing from test to test by a few percent anyway).