4 ms·

Had a similar chat with someone recently after I used Apache for a side project in part because of it's .htaccess feature. This let's you drop .htaccess files

Had a similar chat with someone recently after I used Apache for a side project in part because of it's .htaccess feature. This let's you drop .htaccess files anywhere and Apache will load them on each request for additional server config. https://httpd.apache.org/docs/2.4/howto/htaccess.html https://httpd.apache.org/docs/2.4/howto/htaccess.html One big reason to avoid them was performance; it required extra disk access on every request and it was always better to put the configuration in the main config file if possible. But now? When most servers have an SSD and probably spare RAM that Linux will use to cache the file system? Ok, performance is still slightly worse as Apache has to parse the config on every request as opposed to once, but again, now that most servers have more powerfull CPU's? In many use cases you can live with that. [ Side project is very early version but I'm already using it: https://github.com/StaticPatch/StaticPatch/tree/main https://github.com/StaticPatch/StaticPatch/tree/main ]

rollcat 1y ago
Quoting Rasmus Lerdorf: > I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests. PHP got a very long way since then, but a huge part of that was correcting the early mistakes. > PHP 8 is significantly better because it contains a lot less of my code.
- jarofgreen 1y ago
  I'm not sure in which spirit you mean that, so I'm going to choose "approvingly" :-) I do have thoughts for later about modes which could take all the config from .htaccess files and build them into the main config so then you avoid any performance issues - however you have to do that carefully to make sure people don't include any bad config that crashes the whole server. One of the nice things about using .htaccess files as intended is Apache has the Nonfatal flag on AllowOverride so you can avoid that. https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride https://httpd.apache.org/docs/2.4/mod/core.html#allowoverrid...
  - rollcat 1y ago
    I mean honestly - the "classic" Apache model of throwing things into the www root is very strong for rapid development. Hot code reloading is sometimes finicky, you can end up with unexpected hidden state and lose sanity over a stupid heisenbug. Trust me. IMO you don't need to compensate for bad configs if you're using a proper staging environment and push-button deployments (which is good practice regardless of your development model). In prod, you can offset its main issue (atomic deployments) by swapping a symlink. In that scenario, having a separate .htaccess file actually helps - you don't want to restart Apache if you can avoid it, and again - hot reloading can hide state. My main issue is that this is all a very different model from what most languages, frameworks, and runtimes have been doing for almost 20 years now. If you're a sysop dealing with heterogenous environments, it's honestly just annoying to have separate tooling and processes. Personally, ca 10 years ago, this was the tipping point at which I've demanded from our PHP devs that they start using Docker - I've been reluctant about it until that moment. And then, whether it was .htaccess or the main config, no longer mattered - Apache lived in a container. When I needed to make sure things performed well, I used Locust <https://locust.io/ https://locust.io/>. Just measure, then optimise. So in practice, yes, spiritually I'm doing what PHP8 did to PHP3. Whether that's "approvingly" is up to your interpretation ;)
malwrar 1y ago
I don’t understand why apache wouldn’t just watch the filesystem, this choice means 99.99% of http requests are going to be slowed down by an unnecessary disk reads.
- kragen 1y ago
  When you get a notification from watching the filesystem, you have to read and parse the files. It's simpler to just always read and parse the files, and the <20 milliseconds that takes are not a big deal in many cases. I just tested curl http://canonical.org/~kragen/tmp2.html http://canonical.org/~kragen/tmp2.html on localhost and it generally comes in under 15ms, despite the 2-kilobyte .htaccess in that directory. But 25 years ago it was a significant performance hit. So you might wonder why Apache didn't just watch the filesystem to avoid it. The answer, as best I can reconstruct it, is that only IRIX had a usable filesystem change notification API; Linux had a shitty broken one, and Solaris and FreeBSD didn't have one at all. Linux's inotify is still a pain in the ass, but at least now it's good enough that it can actually work. https://groups.google.com/g/mailing.freebsd.fs/c/T64SiVOfyUE https://groups.google.com/g/mailing.freebsd.fs/c/T64SiVOfyUE has Mark Felder 10 years ago describing it as "a world of hurt", but not having a viable alternative for FreeBSD even then. So 25 years ago there was just no way to do this, so people just got in the habit of turning off .htaccess to make Apache fast. That meant that there was no incentive to make .htaccess fast.

rollcat 1y ago

Quoting Rasmus Lerdorf: > I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests. PHP got a very long way since then, but a huge part of that was correcting the early mistakes. > PHP 8 is significantly better because it contains a lot less of my code.

jarofgreen 1y ago
I'm not sure in which spirit you mean that, so I'm going to choose "approvingly" :-) I do have thoughts for later about modes which could take all the config from .htaccess files and build them into the main config so then you avoid any performance issues - however you have to do that carefully to make sure people don't include any bad config that crashes the whole server. One of the nice things about using .htaccess files as intended is Apache has the Nonfatal flag on AllowOverride so you can avoid that. https://httpd.apache.org/docs/2.4/mod/core.html#allowoverride https://httpd.apache.org/docs/2.4/mod/core.html#allowoverrid...
- rollcat 1y ago
  I mean honestly - the "classic" Apache model of throwing things into the www root is very strong for rapid development. Hot code reloading is sometimes finicky, you can end up with unexpected hidden state and lose sanity over a stupid heisenbug. Trust me. IMO you don't need to compensate for bad configs if you're using a proper staging environment and push-button deployments (which is good practice regardless of your development model). In prod, you can offset its main issue (atomic deployments) by swapping a symlink. In that scenario, having a separate .htaccess file actually helps - you don't want to restart Apache if you can avoid it, and again - hot reloading can hide state. My main issue is that this is all a very different model from what most languages, frameworks, and runtimes have been doing for almost 20 years now. If you're a sysop dealing with heterogenous environments, it's honestly just annoying to have separate tooling and processes. Personally, ca 10 years ago, this was the tipping point at which I've demanded from our PHP devs that they start using Docker - I've been reluctant about it until that moment. And then, whether it was .htaccess or the main config, no longer mattered - Apache lived in a container. When I needed to make sure things performed well, I used Locust <https://locust.io/ https://locust.io/>. Just measure, then optimise. So in practice, yes, spiritually I'm doing what PHP8 did to PHP3. Whether that's "approvingly" is up to your interpretation ;)

malwrar 1y ago

I don’t understand why apache wouldn’t just watch the filesystem, this choice means 99.99% of http requests are going to be slowed down by an unnecessary disk reads.

kragen 1y ago
When you get a notification from watching the filesystem, you have to read and parse the files. It's simpler to just always read and parse the files, and the <20 milliseconds that takes are not a big deal in many cases. I just tested curl http://canonical.org/~kragen/tmp2.html http://canonical.org/~kragen/tmp2.html on localhost and it generally comes in under 15ms, despite the 2-kilobyte .htaccess in that directory. But 25 years ago it was a significant performance hit. So you might wonder why Apache didn't just watch the filesystem to avoid it. The answer, as best I can reconstruct it, is that only IRIX had a usable filesystem change notification API; Linux had a shitty broken one, and Solaris and FreeBSD didn't have one at all. Linux's inotify is still a pain in the ass, but at least now it's good enough that it can actually work. https://groups.google.com/g/mailing.freebsd.fs/c/T64SiVOfyUE https://groups.google.com/g/mailing.freebsd.fs/c/T64SiVOfyUE has Mark Felder 10 years ago describing it as "a world of hurt", but not having a viable alternative for FreeBSD even then. So 25 years ago there was just no way to do this, so people just got in the habit of turning off .htaccess to make Apache fast. That meant that there was no incentive to make .htaccess fast.