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.

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