Hacker News Reader

Comment by rbanffy | Hacker News Reader

What are current use cases for Apache where it is a better choice than, say, Nginx?

Apache has shipped with an event-based backend for many years now, so in terms of architecture it's on par with Nginx (while still supporting the classic pre-forking).

Personally I've found apache is more fully featured for niche use cases. For example you can do client cert authentication, then further look up a username from the certificate in ldap for authorisation - all from your apache configuration. For Nginx many of these niche use cases seem to be gated behind Nginx Plus.

1.) Safe modification of the behavior of the webserver as an unprivileged user (.htaccess)

2.) Sticky Sessions (and various other features) without having to pay $$$ to F5

I end up reaching for Nginx before Apache these days, but I have a lot of production that uses Apache.

One feature of Apache which Nginx annoyingly lacks is HTTP CONNECT support (there is a third-party module from Alibaba which implements it, but it only supports HTTP 1.x).

I prefer Apache because of the development model, the stability of configuration, familiarity, dedication to backwards-compatibility.

I've used Apache for over 20 years and I'm going to give you a feature it's missing: request coalescing.

My servers mostly proxy requests to a backend (PHP-FPM, but this is applicable to all other server-side languages). If m requests come in for /foo and all requests have the same cookies, Apache will pass all m requests through to the backend.

nginx instead will pass one request to the backend and then serve the response to all m requesters, reducing backend load. The setting is called proxy_cache_lock (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...)

With Apache I have to put other software in front of the web server (Varnish usually) that does this for me. So switching to a server where I can reduce installs to support by 50% is appealing.

What are current use cases for, say, nginx where it is a better choice than Apache?

Proxying requests to application servers. Apache can do this, but it's clumsy to set up. nginx handles it much more gracefully.

Haproxy to me is much better. The free version of nginx has absolutely abysmal stats for monitoring.

I second this. NGinx has very powerful controls around content caching but very flimsy controls and monitoring around proxy operations. HAProxy has minimal controls around caching but incredible controls and flexibility with proxy operations. HAProxy is my go-to for the outer ring of my systems. I use NGinx when I need a lot of control around content caching and in that case NGinx is my middle ring. Think CDN model Both compliment each other quite well in various use cases.

I've interacted with the development teams of Apache, NGinx and HAProxy. The lead developer of HAProxy has by far been the easiest to work and interact with.

I’ve been using Apache exactly for that for years and it’s quite easy to setup. Maybe it’s me just being used to it, but I find Apache easier to configure than nginx.

As far as I know Nginx doesn't have the equivalent of an htaccess. This can be quite beneficial for shared hosting.

https://www.nginx.com/resources/wiki/start/topics/examples/l...

Surely that's not true and the maintainers of Apache understand caching?

It's true. If .htaccess is enabled (AllowOverride not set to None), Apache httpd will search for them and parse them on every request. For most use cases, this is honestly fine; it only becomes an issue for very high traffic sites.

Huh. I’m surprised they don’t use fs events to watch for changes rather than doing fs I/O in the critical path.

FS events are OS dependent, don't always work (e.g. on network volumes), and often have a limited number of "watches" available which could easily be exhausted by deep, complex directory structures.

fs events do not scale on linux, at least not with the inotify facility as watching directories is not recursive and watching large trees, e.g. for creations, modifications or removals .htaccess, will essentially require you to have an additional watch descriptor per directory, and there are limits on number of queued events as well as number of watch descriptors per user. The alternate fanotify has it's own set of drawbacks, such as the need for CAP_ADMIN. Not to mention the mess you may get in when you're trying to monitor certain file systems, especially certain network-attached ones.

Other operating systems have drawbacks as well.

It's probably a safer and maybe even more efficient bet to just do the stats and opens and hope that the kernel/OS file system caches will save the day. Or you can go the nginx route and not support .htaccess like facilities (e.g. turn if off in apache).

In theory yes. In practice, how often are people who are using htaccess going to be running into these corner cases? I would bet anyone using it is likely running a very small site anyway where the convenience is worth it.

You can also detect when you have too many watches needed or a network filesystem to fall back to the existing path. It’s a philosophical difference ultimately.

I can't point to code, but from experience, changes usually register quickly.

Changes being adding a new file, changes to an existing one and so on.

While I hadn't thought of it, I haven't noticed issues around it. Using a platform like Drupal, Wordpress, Django, etc most paths don't exist on disk and just fall to the index file or get proxied to another server.

So this might be an issue for static files uploaded or static sites. Talking about Drupal and Wordpress, that would usually be,

    sites/default/files/
    wp-content

They are not making a fair argument. The bottom line is, Nginx offers no way for an unprivileged user to safely modify behavior of the webserver. Yeah, .htaccess is not performant, but high performance isn't always necessary.

Not sure why you posted that? It agrees with what I said that Nginx doesn't support it. There is a use case for htaccess (shared hosting) and Nginx doesn't have a solution for it.

I've stuck with Apache given it is what I know, having used it for over 15 years. Despite its flaws, it does the job pretty well. I'm also more confident that Apache's code is more battle tested. On top of that I disable all the modules I don't need so my attack surface is pretty small. I run a static site so I basically run Apache with only a few of its core modules. I've tried others (especially Caddy) and while I appreciate some of the enhancements, they don't really add any significant improvements for my use cases.

Running CGI scripts.

That really helped me once when I needed to try something using Chez Scheme which doesn't provide network connectivity out of the box. No problem with CGI, though.

Reply on news.ycombinator.com