"Curiosity is the very basis of education and if you tell me that curiosity killed the cat, I say only the cat died nobly." - Arnold Edinborough

I get contacted by advertising agencies fairly regularly. Most of them are similar in their offering, and most of them perform equally badly. I suppose if they performed well they probably wouldn’t be contacting me as they’d already have publishers queueing up to display their ads.

The latest one to join the batch is IronSource which differs from the crowd by offering installer advertising based on InstallerCore. As customary for these types I declined since I’ve never seen an installer based advertising solution that wasn’t basically a scam and based on tricking users into installing the offers. IronSource was persistent, though, and told me how much money a competitor of mine was making, (thanks!) which was indeed a large amount of money.

Furthermore they assured me they were “one of Google’s biggest partners working directly with their compliance team which means we have to follow their strict guidelines.”

Figuring it couldn’t possibly hurt to check it out (this is called foreshadowing) I went to my competitor and downloaded the installer. What I experienced is best described in images, anonymized to protect the innocents who just want to make a lot of money.

Read More

Dealing with errors in nginx can be a frustrating experience if nginx isn’t configured correctly. Sadly, the default value for error log is less than optimal and some of the tricks to getting information from nginx are not obvious. This post is intended to be a reference for the tools nginx provide and how to configure them; as well as a general guide on what’s important when facing issues in nginx.

I will probably be vilified for putting this as the first thing, however. Knowing the basics is the most important part to understanding the more difficult issues not just related to syntax. Don’t skip basic nginx syntax or how an nginx request flows. Once you understand these concepts the non-error issues become far more tangible to work with.

The Error Log

For issues where there’s an error involved, having nginx configured correctly is absolutely essential. The error_log directive should be configured with an error log level of warn, either at server or http level depending on whether you want per-vhost logs or server wide logs.

Read More

During the last few months, I have been working on an nginx book for Packt Publishing. The book is called Instant Nginx Starter and is now published!

My goal with this book was to provide a concise introduction to the nginx configuration in a way that allowed people to build on top of the knowledge I provided. This meshed well with the Instant line of books from Packt as they are intended to be short and get the reader started quickly.

The knowledge contained in this book is basically a structured, revised and expanded upon version of the information on this blog. It provides a red-thread to help you process the configuration format and syntax in a logical way. I’m really satisfied with how this book turned out and I hope it will help some of you.

Check it out on Packt Publishing

Read More

The nginx source install (and by extension package managers) includes two FastCGI configuration files, fastcgi_params and fastcgi.conf that differ only a tiny bit. To this day, they still cause confusion amongst new users due to package managers.

The difference between the two files in the source install is the simple line of:

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

The difference between the two files in most distribution’s package repositories is nothing, they essentially modified fastcgi_params to match fastcgi.conf.

What this line does is tell PHP which file it should execute, without this nginx and PHP cannot work together. This sounds like a good line to include in the shipped FastCGI configuration file and indeed, Igor Sysoev thought so as well. However, due to the configurations of the time, this wasn’t as easy as simply adding it in.

Read More

Version 1.3.13 of nginx is out and with it comes support for Connection: upgrade and Upgrade header, meaning proxying of WebSockets! Many people have been waiting for this and “are websockets in nginx supported?” is one of the most frequent questions in #nginx on freenode. With that out of the way, time to have a look at the nginx WebSocket implementation.

The New Nginx Websockets Configuration Directives

The documentation provided states the configuration as follows:

location /chat/ {
    proxy_pass ​http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";

This is indeed fairly simple and configuring the HTTP version used isn’t even new at all. We can go ahead and improve the versatility a bit by creating a connection variable thus allowing us to move these proxy_set_headers into a generic included file.

map $http_connection $upgrade_requested { 
    default upgrade;
    ''      close;

This makes the variable $upgrade_requested available to proxy_set_header Connection and if connection upgrade wasn’t requested then it will default back to “” to not interfere with normal requests. The idea here being that if you always proxy HTTP/1.1 then you don’t need a location specifically to handle WebSockets.

Connection upgrading seems unlikely to be back ported into the stable branch so if you wish to use this you will have to use the development branch. Thankfully development in nginx does not mean that it’s not run-time stable, it just means that the API might change and as such it only affects module authors. Don’t be afraid to install the development version to play around with this new feature.

Read More

To understand the inheritance model of nginx you first need to know that nginx operates with multiple blocks of configuration. In nginx such a block is referred to as a context, for instance, a configuration directive placed in server context resides within a server { } block just like a directive placed in http context resides in the http { } block.

There are 6 possible contexts in nginx, here in top to bottom order:

  • Global.
  • Http.
  • Server.
  • If.
  • Location.
    • Nested Location.
    • If in location.
    • limit_except.

The default inheritance model is that directives inherit downwards only. Never sideways and definitely never up. This includes scenarios where you rewrite a request internally from one location to another – every directive in the first location is forgotten and only the second location directives apply for the location context.

Read More