Hot on the heels of last month’s NGINX Unit release, we’re back with not one but two fresh versions, 1.11.0 and 1.12.0. Version 1.12.0 is mostly a bug‑fix release, but also adds support for PHP 7.4 in preparation for its general availability (scheduled for late November). NGINX Unit 1.11.0, however, brings two formidable extensions to the table: serving of static files, and application isolation.
Serving Static Files
Static file serving is perhaps the most eagerly awaited new feature in NGINX Unit. Almost since day one, users have been peppering us with requests to support it. The wait is over: starting with version 1.11.0, NGINX Unit can serve static files.
The implementation is rather simple. Remember the routes configuration object? Of course you do – it was introduced in version 1.8.0. As you might recall, a route specifies how to process a request based on its characteristics (such as hostname, URI, or HTTP method). The route’s match object defines those characteristics and the action object specifies the type of processing to perform. When routes was introduced, the only supported action was pass, which forwards the request to an application server or another route. NGINX Unit 1.11.0 introduces the share action:
{
“listeners”: {
“127.0.0.1:8080”: {
“pass”: “routes”
}
},
“routes”: [
{
“match”: {…},
“action”: {
“share”: “/data/www/example.com/”
}
}
]
}
This setup tells NGINX Unit to serve files from the /data/www/example.com/ directory and its subdirectories (the match conditions are omitted for simplicity.) Note that you need to grant NGINX Unit the file system permissions required to access the files.
This initial support for file serving includes the following features:
-
MIME types. NGINX Unit supports a variety of well‑known built‑in types; also, you can add custom types in the
config/settings/http/static/mime_typesobject:“static”: {
“mime_types”: {
“text/plain”: [
“readme”,
“.c”,
“.h”
],“application/msword”: “.doc”
}
} -
URL‑encoded symbols in URIs. You can include URL‑encoded (reserved) characters in both the URIs of static assets requested from applications and the URIs that represent NGINX Unit configuration objects. For example, given the
listenersobject shown above, the first of the following requests is for the file stylesheet.css file in the css assets directory, and the second request is for the values in the/config/settings/https/static/mime_types/text/plainconfiguration object.GET 127.0.0.1:8080/css%20assets/stylesheet.css
GET localhost/config/settings/http/static/mime_types/text%2Fplain/ - Request header fields. NGINX Unit provides
Content-TypeandETagheaders when responding to requests for static files.
Of course, we aim to add many more features in coming releases. For details about configuring static file serving, refer to our docs and how‑tos.
Application Isolation
Unlike static file serving, this new feature may surprise even our most ardent followers. Without much pomp or even extensive advance announcements, NGINX Unit 1.11.0 introduces support for application (process) segregation. First and foremost, this improves the security of NGINX Unit‑hosted apps, allowing them to run in isolated environments based on Linux namespaces (similar to how Docker containers work).
The configuration of the new isolation object is straightforward: you specify the isolation level with the namespaces object and the UID and GID mapping between the host and the container in the uidmap and gidmap objects:
“isolation”: {
“namespaces”: {
“credential”: true,
“pid”: true,
“network”: true,
“mount”: false,
“uname”: true,
“cgroup”: false
},
“uidmap”: [
{
“container”: 1000,
“host”: 812,
“size”: 1
}
],
“gidmap”: [
{
“container”: 1000,
“host”: 812,
“size”: 1
}
]
}
For details, see our docs and Application Isolation with NGINX Unit on our blog.
Other Updates
Another noteworthy update in NGINX Unit 1.11.0 is support for offloading of WebSocket connections for Java Servlet Containers, like that we added for Node.js in NGINX Unit 1.10.0. The required piping is all under the covers, so there’s no need to reconfigure your WebSocket‑based app or patch the code.
Conclusion
In our plans for the immediate future, we are very eager to add proxying to the diverse and potent mix of NGINX Unit’s capabilities. However, if you have any other ideas for spectacular improvement, which our users are usually prone to do, please visit our GitHub repository to join the discussions and development.
Interested in becoming a full‑time engineer for NGINX? Check our job board.
NGINX Plus subscribers get support for NGINX Unit at no additional charge. Start a free 30‑day trial of NGINX Plus today.