NGINX Unit - universal web app server - a lightweight and versatile open source server that simplifies the application stack by natively executing application code across eight different programming language runtimes.
Find a file
Andrew Clayton d5efa5f11f Wasm: Fix multiple successive calls to the request_handler.
When trying to upload files to the luw-upload-reflector demo[0] above a
certain size that would mean Unit would need to make more than two calls
to the request_handler function in the Wasm module we would get the
following error from wasmtime and the upload would stall on the third
call to the request_handler

  WASMTIME ERROR: failed to call function [->wasm_request_handler]
  error while executing at wasm backtrace:
      0: 0x5ce2 - <unknown>!memcpy
      1:  0x7df - luw_req_buf_append
                      at /home/andrew/src/unit-wasm/src/c/libunit-wasm.c:308:14
      2:  0x3a1 - luw_request_handler
                      at /home/andrew/src/unit-wasm/examples/c/luw-upload-reflector.c:110:3

  Caused by:
      wasm trap: out of bounds memory access

This was due to ->content_off (the offset of where the actual body
content starts in the request structure/memory) being some overly large
value.

This was largely down to me being an idiot!

Before calling the loop that makes the calls to the request_handler we
would calculate the new offset, which is now just the size of the
request structure as we don't re-send all the HTTP meta data and headers
etc. However because this value is in the request structure which is in
the shared memory and we use this same memory for requests and
responses, when we make a response we overwrite this request structure
with the response structure, so our ->content_off is now some wacked out
value when we make the next call to the request_handler.

To fix this we just need to reset ->content_off each time round the
loop.

There's also no point in setting ->nfields to 0, it has the same issue
as above, but doesn't get re-used by the Wasm module anyway.

[0]: <https://github.com/nginx/unit-wasm/blob/main/examples/c/luw-upload-reflector.c>

Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2023-09-25 13:52:13 +01:00
auto Wasm: Wire the Wasm language module up to the build system. 2023-08-17 13:09:42 +01:00
docs Version bump. 2023-09-04 12:03:39 +01:00
go Tests: using modules in Go. 2022-01-10 16:07:31 +03:00
pkg Generated Dockerfiles for Unit 1.31.0. 2023-08-23 11:29:07 +00:00
src Wasm: Fix multiple successive calls to the request_handler. 2023-09-25 13:52:13 +01:00
test Tests: added tests for the "response_headers" option. 2023-09-04 12:25:36 +01:00
tools Tools: setup-unit: ctl: added "edit" subcommand. 2023-06-30 14:35:59 +02:00
.gitattributes Set git diff driver for C source code files. 2022-10-26 01:23:02 +01:00
.gitignore Added .gitignore. 2022-05-03 12:41:36 +02:00
.hgignore Added .hgignore file. 2020-09-18 19:37:56 +01:00
.hgtags Fixed tag for 1.31.0 release. 2023-08-30 09:07:24 -07:00
.mailmap Using names in .mailmap. 2023-05-21 01:06:26 +02:00
CHANGES Added version 1.31.0 CHANGES. 2023-08-28 17:51:45 +01:00
CODE_OF_CONDUCT.md Adding the NGINX Code of Conduct to the repo. 2023-03-07 13:05:41 +00:00
configure Added unit pkg-config file. 2023-08-01 10:16:17 -07:00
CONTRIBUTING.md Adding GitHub-styled README and CONTRIBUTING files in Markdown. 2022-05-13 17:13:23 +01:00
LICENSE Added LICENSE and NOTICE files. 2017-09-06 18:26:37 +03:00
NOTICE Updated copyright notice. 2023-05-24 16:27:24 +01:00
README.md Update README.md for Docker Official Image. 2023-08-01 16:06:36 +02:00
SECURITY.txt Added security.txt. 2022-11-24 15:06:54 +00:00
version Version file bump. 2023-09-04 14:06:21 +01:00

NGINX Unit

Universal Web App Server

NGINX Unit Logo

NGINX Unit is a lightweight and versatile open-source server that has two primary capabilities:

  • serves static media assets,
  • runs application code in seven languages.

Unit compresses several layers of the modern application stack into a potent, coherent solution with a focus on performance, low latency, and scalability. It is intended as a universal building block for any web architecture regardless of its complexity, from enterprise-scale deployments to your pet's homepage.

Its native RESTful JSON API enables dynamic updates with zero interruptions and flexible configuration, while its out-of-the-box productivity reliably scales to production-grade workloads. We achieve that with a complex, asynchronous, multithreading architecture comprising multiple processes to ensure security and robustness while getting the most out of today's computing platforms.

Quick Installation

macOS

$ brew install nginx/unit/unit

For details and available language packages, see the docs.

Docker

$ docker pull unit

For a description of image tags, see the docs.

Amazon Linux, Fedora, RedHat

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && yum install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Debian, Ubuntu

$ wget https://raw.githubusercontent.com/nginx/unit/master/tools/setup-unit && chmod +x setup-unit
# ./setup-unit repo-config && apt install unit
# ./setup-unit welcome

For details and available language packages, see the docs.

Running a Hello World App

Unit runs apps in a variety of languages. Let's consider a basic example, choosing PHP for no particular reason.

Suppose you saved a PHP script as /www/helloworld/index.php:

<?php echo "Hello, PHP on Unit!"; ?>

To run it on Unit with the unit-php module installed, first set up an application object. Let's store our first config snippet in a file called config.json:

{
    "helloworld": {
        "type": "php",
        "root": "/www/helloworld/"
    }
}

Saving it as a file isn't necessary, but can come in handy with larger objects.

Now, PUT it into the /config/applications section of Unit's control API, usually available by default via a Unix domain socket:

# curl -X PUT --data-binary @config.json --unix-socket  \
       /path/to/control.unit.sock http://localhost/config/applications

{
	"success": "Reconfiguration done."
}

Next, reference the app from a listener object in the /config/listeners section of the API. This time, we pass the config snippet straight from the command line:

# curl -X PUT -d '{"127.0.0.1:8000": {"pass": "applications/helloworld"}}'  \
       --unix-socket /path/to/control.unit.sock http://localhost/config/listeners
{
    "success": "Reconfiguration done."
}

Now Unit accepts requests at the specified IP and port, passing them to the application process. Your app works!

$ curl 127.0.0.1:8080

      Hello, PHP on Unit!

Finally, query the entire /config section of the control API:

# curl --unix-socket /path/to/control.unit.sock http://localhost/config/

Unit's output should contain both snippets, neatly organized:

{
    "listeners": {
        "127.0.0.1:8080": {
            "pass": "applications/helloworld"
        }
    },

    "applications": {
        "helloworld": {
            "type": "php",
            "root": "/www/helloworld/"
        }
    }
}

For full details of configuration management, see the docs.

OpenAPI Specification

Our OpenAPI specification aims to simplify configuring and integrating NGINX Unit deployments and provide an authoritative source of knowledge about the control API.

Although the specification is still in the early beta stage, it is a promising step forward for the NGINX Unit community. While working on it, we kindly ask you to experiment and provide feedback to help improve its functionality and usability.

Community

  • The go-to place to start asking questions and share your thoughts is our Slack channel.

  • Our GitHub issues page offers space for a more technical discussion at your own pace.

  • The project map on GitHub sheds some light on our current work and plans for the future.

  • Our official website may provide answers not easily found otherwise.

  • Get involved with the project by contributing! See the contributing guide for details.

  • To reach the team directly, subscribe to the mailing list.

  • For security issues, email us, mentioning NGINX Unit in the subject and following the CVSS v3.1 spec.