Backstory: Since I first started running my own servers several years ago, I’ve always used NGINX as my web and proxy server. I started on a lower-end VPS and needed the spare resources it offered me over the default Apache installation, so I went through the effort of learning how to configure it from a coworker, moving all of the settings from scattered .htaccess files to a set of site configuration files.

Fast forward 5 or so years to now, when I’m stuck inside avoiding my stressful academic responsibilities (mostly subconsciously) by finding distractions. The other day I was poking around on r/selfhosted and I found a post about photo file sharing. After my previous photo gallery mess, I opened it to see what it had to say. It turned out to be nothing interesting, they just wanted to share a folder with their webserver. I do this for one of my sites, but NGINX’s auto-indexing is super ugly (it’s just a <pre> with some tabular text output in it). One of the comments suggested such auto-indexing and included a screenshot of Caddy’s index page, which is much nicer looking than NGINX’s. I didn’t know what Caddy was, and the comment didn’t mention it by name, but I assumed it was a program for showing pretty index pages based on the “Served with Caddy” footer text in their screenshot.

This led me to look it up, and I discovered it’s a new web server written in Go that does a lot of work (especially SSL) for you and has nicer, flexible config files. I thought this sounded a lot better than NGINX, so I set out installing it.

Of course they don’t have an OpenSUSE package I can install on my server, so I used the Docker image and kept going. Then I couldn’t figure out how to apply config rules to paths, only domains, and the syntax errors thrown when I tried things listed in the docs (which are missing a lot of information) and online were less than helpful.

I gave up and tried to get it to just run first, but I couldn’t get SSL working because the server is behind Cloudflare. (I am aware there is a Cloudflare DNS module for its auto-SSL feature, but all the documentation was for 1.x, not 2.0, so I had no idea how to enable it and I was too frustrated to deal with it.)

It provided about an hour of interesting frustration, but in the end I decided it needs a little more development before I’m ready to try it again. They even officially released version 2.0 about 2 days after this all happened.

Eventually, I got bored again and realized that maybe I didn’t need NGINX anyway. What was wrong with Apache now that I have several gigs of memory to spare at any given time? I then rationalized that having one giant config file in the depths of my server was dumb considering all of the smaller webapps running from the web server directory. Shouldn’t they be able to decide their own server configuration, with .htaccess or something?

After another hour of trying to figure out how Apache’s virtual hosts work, I was ready to configure SSL. Certbot easily figured out how to handle this for me, and generated an additional configuration file for each virtual host site file with pretty much exactly the same code, so I combined them into one file per domain. Still a lot of duplicated code. And my redirects weren’t working right. Whatever, I’ll figure that out later.

Time to set up PHP for that one old site I still have to run for family. NGINX was using PHP FPM 7.0, but Apache uses a module instead of PHP FPM, so I installed the correct version of PHP for it. Which was still 7.0. Wait, 7.0? That’s old. Oh, because this VPS is running Ubuntu 16.04. Because my host uses OpenVZ and refuses to support anything newer. Right.

After adding a custom PPA to install PHP 7.4, I now had a nearly-fully-working site in Apache. Except the duplicated config still bugged me. And my wildcard SSL certificate wasn’t working correctly. So as is typical of me lately, I uninstalled everything new and went back to NGINX. However, I installed PHP FPM 7.4 to speed things up and make it a bit more secure. And now I have blank white pages?

Oh, no, don’t tell me that old family website uses short open tags!

Anyway, this site apparently used them. Rather than enable the option in the config file for the new PHP version, I decided to do things right for once: I went through the code and replaced them all with the full open tags.

Now I have NGINX running PHP 7.4. Not much as changed, but I’ve learned a few things along the way:

  • Caddy still looks really cool, but is not ready for production or even my own use yet (maybe once the documentation is all moved over to the 2.0 release?)
  • Apache’s configuration is irritating and not worth having .htaccess files over a few extra lines in NGINX’s configuration. I understand why it’s useful for shared hosting, but it’s not for me.
  • NGINX’s config may seem clunky compared to Caddy’s, but I’ve gotten so used to it over the years that anything simpler feels like I’m giving up too much control.
  • I need to do things that are more productive and/or more fun than tinkering with web servers

That’s the end of the post.

For your own mental health, please stop reading.

Close this page.

Go do something else.

Anything.

If you’re reading this far, you’re disobedient and are about to be cursed for it.

Point of no return⌗

While scrolling through my newly-installed PHP 7.4 php.ini, I scrolled farther down than I had even gone before, and I discovered a few options that are new to me, the worst of which I have copied here:

; This directive determines which super global arrays are registered when PHP
; starts up. G,P,C,E & S are abbreviations for the following respective super
; globals: GET, POST, COOKIE, ENV and SERVER. There is a performance penalty
; paid for the registration of these arrays and because ENV is not as commonly
; used as the others, ENV is not recommended on productions servers. You
; can still get access to the environment variables through getenv() should you
; need to.
; Default Value: "EGPCS"
; Development Value: "GPCS"
; Production Value: "GPCS";
; http://php.net/variables-order
variables_order = "GPCS"

I cannot understand why someone would ever need to change the order in which these are set. I’m honestly a little afraid of ever seeing a PHP program that would dare to state in their installation instructions:

Hey, by the way, our developers decided to turn to the dark arts to get this program developed. As a result, you need to change variables_order to G̷̛̻̤̞͐̇̓̀̀͑̅̓̇̕͝͝P̸̨̡̛̼͕͎̩̯̳̰̫̘͉͔̘̩̲͌̑̊̍͛͑̏̾͗̓͛̋͛͝͝ͅC̷̢̨̞͍͍͐̃̓̃͝S̸̛̯͂̅̒͒̾̌̃̇̕̕ in your php.ini to use this program.

I truly hope this is a case of the PHP developers having to make a decision about the ordering, realizing it is arbitrary, and offering the user the option to customize it. I’m also guilty of offering unnecessary options. If this isn’t unnecessary, I don’t want to know why. Okay, I kind of do. But I’m sure it’s not healthy to know.