Send additional HTTP headers to Nginx’s FastCGI

It’s not that often that I come across a useful, but undocumented feature in a major software application.  It happened recently, so I’ll document it here just for the future self.

For a particular setup, I had to send additional HTTP headers (let’s use X-GEOIP for this example) to the PHP-FPM, which was configured as a FastCGI backend in Nginx web server.  This StackOverflow thread suggested several solutions, but this one was the easiest and worked like a charm: use Nginx’s fastcgi_param directive AND prefix your variables with HTTP_.  For example:

location ~ \.php$ {
  fastcgi_param HTTP_X_GEOIP $geoip;
  ... other settings
}

 

macOS in the cloud

With the constant expansion of cloud providers and services, one would think everything is possible and easy these days.  Well, at work, we came across an interesting project which shed some light on the lesser discussed areas of cloud providers and services – macOS.

Both Linux and Windows are well suited for the cloud, and are widely covered.  macOS though not so much.  Why?  Well, there are many reasons, but one of them might be that short, but annoying paragraph in the software license agreement (this one is for Catalina, but you can easily check the others here):

J. Other Use Restrictions. The grants set forth in this License do not permit you to, and you agree not to, install, use or run the Apple Software on any non-Apple-branded computer, or to enable others to do so.You agree not to remove, obscure, or alter any proprietary notices (including trademark and copyright notices) that may be affixed to or contained within the Apple Software. Except as otherwise permitted by the terms of this License or otherwise licensed by Apple: (i) only one user may use the Apple Software at a time, and (ii) you may not make the Apple Software available over a network where it could be run or used by multiple computers at the same time. You may not rent, lease, lend, sell, redistribute or sublicense the Apple Software.

Yup.  You have to run Apple software on the Apple hardware.  This alone is a huge showstopper for the cloud.  And only user may use it at a time too.

There are still some cloud providers who offer specifically macOS based products and services (and yes, they run them on the Apple hardware).  Here are a few examples, thanks to this thread:

It’s good to have options here, even if the prices are much higher than what you’d expect.

Toptal: The Suddenly Remote Playbook

Toptal is one of the great companies that I have my eyes on.  If you haven’t heard of them, here’s a brief intro:

Toptal is an exclusive network of the top freelance software developers, esigners, finance experts, product managers, and project managers in the world. Top companies hire Toptal freelancers for their most important projects.

I’ve had some interactions with the company in the past, and I’ve heard plenty of stories from other people.  These guys definitely know what they are doing.

And if you don’t believe me, here’s some proof for you.  The COVID-19 pandemic forced a lot of companies, teams, and people to work remotely.  Some were ready for this, but most had to make major adjustment.  Many are still struggling.  Toptal though is not one of them.  They’ve been doing remote work for a long time now.  Lucky for the rest of us, they’ve shared a lot of that in a rather concise, to the point, easy to read document, titled “The Suddenly Remote Playbook“. It is a playbook for sustaining an enterprise-grade remote work environment, from the world’s largest fully remote company.

It doesn’t matter whether you are just starting with the remote work, or have been doing it for a long time, I promise you, you’ll find plenty of useful information in there.

From the simple and direct quotes like:

People are the most important element of any company, remote or not.

To an impressive list of tools like:

  • Slack
  • Grammarly
  • Zoom
  • Krisp.ai
  • Google G Suite
  • Miro
  • Collabshot
  • Loom
  • Trello
  • Asana
  • Confluence
  • Zapier
  • … and more.

Strongly recommended for reading, studying, and implementation!

Caddy – The Ultimate Server with Automatic HTTPS

Great things are easy to get used to.  When something works the way you want it, and does so for a long a time, it is inevitable that one day you’ll stop thinking about it altogether and accept it as a given.

Apache was a great web server, until Nginx came along.  All of a sudden, it became obvious how much faster things could be, and how much simpler the configuration file is possible.

For the last few years, Nginx was working great for me.  And now that I came across Caddy, I realized that life can be a lot simpler.

Caddy web server

Here’s a bit to get you started:

Caddy simplifies your infrastructure. It takes care of TLS certificate renewals, OCSP stapling, static file serving, reverse proxying, Kubernetes ingress, and more.

Its modular architecture means you can do more with a single, static binary that compiles for any platform.

Caddy runs great in containers because it has no dependencies—not even libc. Run Caddy practically anywhere.

Seriously? We now have a web server which handles HTTPS with automatically renewed certificates (yes, Let’s Encrypt) out of the box… Mind-blowing.  I guess, 21st century is indeed here now.

What else is there?  Well, let’s see:

  • Configurable via RESTful JSON API. OMG!  No more trickery with include files, syntax checking and restarts.  In fact, configuration files are completely optional, and even if you choose to use them, they just use the same API under the hood.  Bonus point: you can export full configuration of a running server into a file via a simple API call.
  • Extensible.  Yes, that’s right!  “Caddy can embed any Go application as a plugin, and has first-class support for plugins of plugins.”  Check out their forum for plugin-related discussions, or simply search GitHub for Caddy.
  • Supports HTTP/1.1, HTTP/2, and even HTTP/3 (ETF-standard-draft version of QUIC), WebSocket, and FastCGI.
  • … and a lot more.

Wow!  It’s definitely worth checking out.  While Nginx is not going to disappear (much like Apache being still around), Caddy might be a better option for your next project.

A practical guide to writing technical specs

Writing technical specifications is difficult.  Writing good technical specifications is even more so.  Here’s an excellent practical guide from StackOverflow on how to write technical specifications, which have everything needed, yet not being too excessive or vague.

In the comments, there are a few additional suggestions and links to other similar guides.

The only way this could have been better, if they included a ready-made template with all the described sections, so that one could just fill it in and be done with it.