Hacker News Reader

Comment by cestith | Hacker News Reader

Lots of companies that have been around a while and haven't replaced legacy applications still run those behind the web server they were designed to run behind. Moving to another server seems simple until you actually try to do that with a handful of 15-year-old sites with proxy rules, rewrites, custom headers, and such in one server's central config file and a bunch of per-directory access files. Technical debt is a real thing.

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.

View on HN

That's not debt. Those are working configurations on a fully supported web server with active development. There is zero reason to change them.

This. There's nothing wrong with using mature technology that is still being developed. LAMP is still a perfectly fine choice if it's what you want to use.

> This. There's nothing wrong with using mature technology that is still being developed.

Surely this decade they've squashed the last bugs that nginx or anything newer won't have...

Tying that kind of business logic with http server is a technical debt. Not by 90s standards maybe.

So putting these config in .htaccess which live in project folder is a technical debt, but putting all these logics in nginx master config file is not?

When the reason a team can't unbind from one technology in favor of county and that reason is old decisions that we won't make today, that's a form of debt. If you're choosing to stick white Apache for a good reason it's not debt.

I don't think we disagree here. If old systems stay with a legacy technology and do other work instead of changing that foundation, then staying with the legacy technology can become technical debt - not the decision itself, back in the day.

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.

And Apache supports .htaccess files which are great for hosting (nginx doesn't, afaik).

Not by default, but since nginx is pretty flexible you can implement support for it, and it seems like people have.

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.

I don't agree with the downsides - what you are describing is simply a bad implementation of this mechanism. At the very least, the files could only be checked every 5 seconds, or inotify or similar mechanism could be used.

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.

Reply on news.ycombinator.com