Summer’s gone, so it’s time to forfeit the halcyon tranquility and get some working attitude on. The NGINX Unit team has recently presented our first two‑digit version, NGINX Unit 1.10.0; let’s page through the recent developments and shed some light on our plans for the future.
Routing Advancements
In our two latest releases, some major effort went into extending the request routing capabilities that were initially introduced in NGINX Unit 1.8.0. Version 1.9.0 included essential support for arguments, headers, and cookies in matching clauses, whereas NGINX Unit 1.10.0 added scheme‑based routing to the mix. A few examples:
“match”: {
“host”: “www.example.com”,
“arguments”: {
“mode”: [“mobile”, “desktop”],
“ui”: “!full”
}
}This condition matches queries like www.example.com/?mode=mobile and www.example.com/?mode=desktop&ui=compact, but not www.example/com/?mode=desktop&ui=full.
“match”: {
“headers”: [
{
“Accept-Encoding”: “*gzip*”,
“User-Agent”: “Mozilla/5.0*”
},
{
“User-Agent”: “curl*”
}
]
}
This clause matches only requests where the User-Agent header is either Mozilla/5.0 (and gzip compression is also applied) or curl.
“match”: {
“host”: “example.com”,
“scheme”: “https”
}This condition matches https://example.com, but not http://example.com.
Pattern matching was also extended to allow wildcards in the middle of the match string:
“match”: {
“host”: [“eu-*.example.com”, “!eu-5.example.com”]
}This clause happily matches all eu- subdomains of example.com except eu-5.example.com.
Configuration Updates
The config API received some polishing as well. Most importantly, it now supports non‑idempotent POST semantics. In less fancy terms, this means you can append new items to arrays, which do occur in NGINX Unit configuration. For instance, consider this sample output from a curl query to NGINX Unit’s control socket:
# curl –unix-socket /path/to/control.unit.sock http://localhost/config/
{
“listeners”: {
“*:8000”: {
“pass”: “routes”
}
},
“applications”: {
“blogs”: {
“type”: “python”,
“module”: “wsgi”,
“path”: “/www/blogs/”
}
},
“routes”: [
{
“match”: {
“host”: [
“dev1.example.com”,
“dev2.example.com”
]
},
“action”: {
“pass”: “applications/blogs”
}
}
]
}
Let’s decipher the JSON: the configuration includes an application called blogs, a routes section that allows access to the app via two hostnames, and a listener that passes incoming requests through the routing engine. Using the POST method, we append a new hostname to the host array:
# curl -X POST -d ‘”dev3.example.com”‘ –unix-socket=/path/to/control.unit.sock \
http://localhost/config/routes/0/match/host/
{
“success”: “Reconfiguration done.”
}Note that all responses from NGINX Unit are also encoded in JSON. Next, I make a curl query to display just the routes section:
# curl –unix-socket /path/to/control.unit.sock http://localhost/config/routes/
[
{
“match”: {
“host”: [
“dev1.example.com”,
“dev2.example.com”,
“dev3.example.com”
]
},
“action”: {
“pass”: “applications/blogs”
}
}
]
As you can see, the POST operation appended its payload to the end of the host array. It’s worth mentioning here that NGINX Unit changes only the sections of the configuration that are affected by the update, calculating the difference between the old config and the new on the fly to minimize overhead. Handy!
In other news, we’ve also done away with a few nasty bugs, making config manipulation more reliable.
Application Languages
Most of the latest changes in language support are for Node.js, including a new built‑in WebSocket server implementation in NGINX Unit 1.10.0. To use it, just specify our module as the parameter to the require function instead of the native websocket module:
var webSocketServer = require(‘unit-http/websocket’).server;In addition, NGINX Unit 1.10.0 adds some axle grease to improve integration with the latest Node.js versions; a few compatibility bugs were fixed as well.
Another significant update to language support is the PHP module’s new ability to parse request URIs into the PATH_INFO environment variable – something many PHP developers have come to rely on. The change might appear tiny, but it makes it easier to run some major apps like NextCloud, as detailed in the shiny new how‑to we’ve provided for your convenience. Oh, and speaking of…
Documentation
Our documentation has been extended significantly in the last few months with various guides and how‑tos in response to your insightful queries, friendly GitHub rants, and reasonable – but misplaced – assumptions about how some features work.
Some of the major updates include a guide to running NGINX Unit in Docker that is accompanied by a sample Dockerfile for each of the supported languages, an end-to-end guide on language module manipulation, and how‑tos for popular apps and frameworks like Catalyst and Redmine (along with the aforementioned NextCloud). There’s more to come – please check the docs once in a while or post your “gotta see this app run on NGINX Unit” ideas on GitHub.
Conclusion
The journey continues, and NGINX Unit is gaining momentum. Our team is steadily growing with new people bringing new ideas, so follow us for more exciting news (which we already have in the works): see the recent updates in the changelog or monitor our GitHub repository to join the discussions and development.
Finally, a few words about future updates. At this moment, we are working hard to bring to life such long‑promised features as WebSocket support for Java, serving static assets, and proxying. Our team is quite serious about making NGINX Unit a really busy little web engine. Stay tuned!
Interested in becoming a full‑time engineer for NGINX? Check our job board.