It’s mentioned, but I feel like the article undersells the incredible synchronicity of at least the AP of the LAMP stack. Like the cgi-bin before it, PHP was stupidly easy to deploy onto a web server. Just drop in your files and go. No managing extra servers for web apps or anything like that really. This meant it was stupidly easy to allow clients/users/etc. to run dynamic content with PHP.
With basically every “modern” web platform outside of PHP, you’re either
relying on more servers you run that get proxied to (e.g. dynamic applications in Python, Go, Node, etc.)
building static content and relying on 3rd parties if you want to inject any dynamicness
so it’s definitely more of a process. It’s interesting seeing companies like Heroku or Fly.io appearing which offer something as close to the old Web Hosting Company “fire and forget” for modern apps that need some kind of server component, but I still wonder how in the long run it’ll affect newer developers who, outside of these handful of services, need to basically become full sysops to built out their own stack on a VPS since you can’t just dump your content on a web host and call it a day anymore.
Unfortunately, the mod_php model was a security nightmare for shared hosting, which is where some of the LAMP-hatred comes from. mod_php was in-process for Apache and so ran as whatever user httpd ran as. This user had to have, at least, read-only access to every user’s public_html directory. It didn’t matter for static hosting that Apache could read everyone’s public_html directory because (almost) everything there was expected to be shared with the Internet. Unfortunately, with PHP, you ended up with secrets in your public_html: in particular in a LAMP stack you’d have the password for the database. Another user could write a .php file that just read your .php file and dumped the output and Apache would happily then tell everyone your database password. Even if no one on the same system did this maliciously, a load of off-the-shelf PHP things came with bugs that allowed someone who sent the right HTTP request to dump the contents of an arbitrary file on the filesystem that Apache could read.
This was made even worse by the fact that Apache ran as root until the early 2000s. I saw a few systems have their shadow password file leaked because a PHP file allowed arbitrary filesystem reads and Apache was running as root.
Right, I remember deploying applications felt a lot easier than now, where there’s some kind of prior knowledge you have to have with i..e Docker, versus “ftp it and follow the setup for database”. Plus it’s dead simple for adding quick little scripts or interactivity to existing sites. I think PHP isn’t as good for complex stuff, but that’s the curse of being able to get going quickly.
Exactly. I don’t know how/why Apache decided to bake PHP in, but that was a kingmaker that made PHP ubiquitous despite it being IMHO a deeply terrible language. Even I got sucked in by the simplicity and used PHP for about a year circa 2005 before giving up in disgust. (In fairness, some of the blame lay with the crappy quality of libraries. I remember a supposedly-complete WebDAV library I had to basically gut and rewrite.)
Apache didn’t, they just provided an extension system to allow people to do all sorts of stuff, like embed language runtimes. mod_php was always written and provided by PHP themselves.
With mod_php you renamed an HTML file to .php, added <?php tags, and went from there. The problems with that show up if you try to color outside the lines, but for a lot of applications, you don’t need to do that.
LAMP is great, although I’m using LASP for many years now: Linux + Apache + SQLite + php-fpm. Even for new web projects this is a pretty good choice! I must admit, I do use a little Go where PHP doesn’t cut it (non-web, daemons, concurrency).
It’s mentioned, but I feel like the article undersells the incredible synchronicity of at least the AP of the LAMP stack. Like the
cgi-binbefore it, PHP was stupidly easy to deploy onto a web server. Just drop in your files and go. No managing extra servers for web apps or anything like that really. This meant it was stupidly easy to allow clients/users/etc. to run dynamic content with PHP.With basically every “modern” web platform outside of PHP, you’re either
so it’s definitely more of a process. It’s interesting seeing companies like Heroku or Fly.io appearing which offer something as close to the old Web Hosting Company “fire and forget” for modern apps that need some kind of server component, but I still wonder how in the long run it’ll affect newer developers who, outside of these handful of services, need to basically become full sysops to built out their own stack on a VPS since you can’t just dump your content on a web host and call it a day anymore.
Unfortunately, the
mod_phpmodel was a security nightmare for shared hosting, which is where some of the LAMP-hatred comes from.mod_phpwas in-process for Apache and so ran as whatever userhttpdran as. This user had to have, at least, read-only access to every user’spublic_htmldirectory. It didn’t matter for static hosting that Apache could read everyone’spublic_htmldirectory because (almost) everything there was expected to be shared with the Internet. Unfortunately, with PHP, you ended up with secrets in yourpublic_html: in particular in a LAMP stack you’d have the password for the database. Another user could write a.phpfile that just read your.phpfile and dumped the output and Apache would happily then tell everyone your database password. Even if no one on the same system did this maliciously, a load of off-the-shelf PHP things came with bugs that allowed someone who sent the right HTTP request to dump the contents of an arbitrary file on the filesystem that Apache could read.This was made even worse by the fact that Apache ran as root until the early 2000s. I saw a few systems have their shadow password file leaked because a PHP file allowed arbitrary filesystem reads and Apache was running as root.
Right, I remember deploying applications felt a lot easier than now, where there’s some kind of prior knowledge you have to have with i..e Docker, versus “ftp it and follow the setup for database”. Plus it’s dead simple for adding quick little scripts or interactivity to existing sites. I think PHP isn’t as good for complex stuff, but that’s the curse of being able to get going quickly.
Exactly. I don’t know how/why Apache decided to bake PHP in, but that was a kingmaker that made PHP ubiquitous despite it being IMHO a deeply terrible language. Even I got sucked in by the simplicity and used PHP for about a year circa 2005 before giving up in disgust. (In fairness, some of the blame lay with the crappy quality of libraries. I remember a supposedly-complete WebDAV library I had to basically gut and rewrite.)
Apache didn’t, they just provided an extension system to allow people to do all sorts of stuff, like embed language runtimes. mod_php was always written and provided by PHP themselves.
mod_perlandmod_pythonwere the main contemporary competitors that I remember.TIL mod_php wasn’t actually an Apache-produced thing. Neat.
If it wasn’t specifically Apache’s holy solution, I do wonder why it picked up so much steam over the alternatives though?
With
mod_phpyou renamed an HTML file to.php, added<?phptags, and went from there. The problems with that show up if you try to color outside the lines, but for a lot of applications, you don’t need to do that.LAMP is great, although I’m using LASP for many years now: Linux + Apache + SQLite + php-fpm. Even for new web projects this is a pretty good choice! I must admit, I do use a little Go where PHP doesn’t cut it (non-web, daemons, concurrency).