Shared hosting is still huge for small sites, and the major control panels for that (cPanel, Plesk, DirectAdmin, vDeck) still support Apache as the primary web server.
Surely this decade they've squashed the last bugs that nginx or anything newer won't have...
But Apache is not a legacy system and still a completely valid choice, next to alternatives like nginx and caddy that have their own advantages and disadvantages. There is no reason to swap Apache out by default, apart from maybe sometimes in specific situations.
There are some downsides with .htaccess files though; since it can change you need to at least check if it was modified since the last request, and since it's recursive (i.e. /foo/.htaccess applies to /foo/bar/file.txt) you may need to check several locations. Basically, it's a lot of stat() calls for every request.
The upside is that it's convenient; i.e. "tar xf somephpapp.tar.gz" and it "just works" without mucking about with configuration to disallow certain files, but this convenience comes with a fairly hefty performance impact, and it's only certain types of PHP apps that really take advantage of this.
The main upside is that it is possible for sysadmin to allow 3rd party users to change parts of http server config via ftp (!). And last I checked, php was dominating web landscape - I would argue that the convenience of deploying plays a large part in this.
Plugins... If it is not part of original app, can I trust it will stay available? I might as well use Apache instead.
https://news.netcraft.com/archives/category/web-server-surve...
For example, Nginx's standpoint on htaccess is basically "find yourself another web server" (https://www.nginx.com/resources/wiki/start/topics/examples/l...). I don't fancy giving users access to /etc/nginx and the power to reload the config just to add aliases on their own subdomains. Much better if they can add password protection to a directory by themselves. It also breaks that each site can live in its own project directory: without htaccess, if I copy over a project I would also have to modify my global nginx config to set per-directory (or at least per vhost) aliases, error pages, etc. Right now, I can say that deploying a project is "download the directory into the desired location and configure your database credentials and a pepper in the config.php". No global configuration changes are ever needed, the global config only does global stuff: tls ciphers, fallback error pages, compression, log files, and more such things.
And that's ignoring the fact that, even if there was some objectively better web server, I'd have the task of rewriting a decade of htaccess files into their fancy new format while Apache2 is still alive and properly supported.
An Apache compiled with the exact options that you'll need shines, like an Nginx well done.
A lot of people still retain the notion that nginx is "just faster" or "just better" which is not necessarily the case. Apache with mpm-event is just fine for most applications.
There are other reasons to use nginx, and there are other reasons to use Apache. Both are fine, and I hear https://caddyserver.com/ is coming in hot!
Smaller web servers have been event based since they first showed up, it is the natural way to build them. There was no epoll() available, but a select() loop is pretty much the same thing. The super useful thttpd had been around a long time at that time.
What caused people to start using non-forking web servers for regular public web applications was probably that PHP finally got a stable FastCGI mode going about ten years ago. Because, honestly, most of the web is PHP and it was even more dominant back them.
And when people posted their web server configs in forums at that time, nginx configs were much more readable and concise. The easier config format is what caused its popularity to soar, not that it used a particular syscall half a decade earlier.
Before nginx, lighttpd was a thing. It also comes with `spawn-fcgi` to handle fastcgi, but it's a little complex to set up. Back then people were also using `spawn-fcgi` with nginx, too. I remembered reading some tutorial and decided that I will continue to use Apache with mod_php due to complexity. When php-fpm come, I immediately switched.
At the expense of the memory footprint because developed with Go. Hi Caddy creator!
Makes sense to me that something built in a language with more memory safety than C would use more memory, but is it really significant in practice? I use go every day and memory usage has not been a significant issue for many applications.
There are other performance concerns of course, e.g. GC latencies, and at times the GC may bite you. See e.g. the "taming Go memory usage" story from a few days ago[1], but this usually isn't a huge concern for many use cases.
cmon now
terminal systems engineer brain is everywhere
$ apt-get install python3-certbot-nginx
$ sudo certbot --nginx -d example.com -d www.example.com
https://www.nginx.com/blog/using-free-ssltls-certificates-fr...
On the other hand, caddy seems to auto renew them as well - one less cron job:
> Automatic HTTPS provisions TLS certificates for all your sites and keeps them renewed.
https://caddyserver.com/docs/automatic-https
Neat, but still not sold.
Overall, the entire thing seems very complex automagic black box last time I tried it (already years ago). Sometimes trying to make something easier can make it harder.
Web servers have historically been pretty conservative as far as software goes.
Edit: specific to your request, I would probably set up a container pointing to the latest apache build, and write a script to pull the latest image then roll over the container... Don't need to wait for your OS of choice to have the fixed versions... Your never more than a day behind
darkhttpd is an option
Now if someone asks me if I also still use the same laptop as when Apache had >6 times the market share of Nginx (https://news.netcraft.com/archives/category/web-server-surve...), I will need to find more hands.
Unlike nginx or Caddy^H^H^H^H^H, the Apache design and community encouraged writing modules (roughly akin to "middleware" in the modern server-side web stack) that hooked directly into the web server, rather than just using it as a static host + L7 proxy.
Furthermore, these modules could themselves expose language-specific APIs; ergo `mod_perl` and its ilk, which provide a bunch of useful building blocks for a full-stack webapp but are entirely specific to Apache's module API (vs. something more standard like FCGI, WSGI, etc.)
I've worked at some shops with heavy investments in Apache-based application servers and the cost of moving away from HTTPD modules and towards a more standalone, Apache-free implementation was generally quite high. Usually you need some other forcing function (rewrite in a new language, microservice decomposition, etc.) to justify the investment.
Huh? I must be misunderstanding, because everything in Caddy is a module, even its HTTP server, and all its middleware handlers are equally modules that you can plug in as much as any other module you could write and publish.
Some Caddy modules also expose dynamic scripting / language interpretation capabilities as well. Caddy is used for well more than just static files and HTTP reverse proxying.
A similar number of folks as are using nginx[0]
It's very stable, supports that one special thing many sites need (special headers, stripping file extensions, caching etc) and has excellent documentation.
It's not fashionable, but it will still be unfashionable in another 10 years, and we won't have needed to update the configurations in that time.
I thought I was so cool ...