Andrew Clayton dad7ef9a12 Configuration: made large_header_buffer_size a valid setting.
@JanMikes and @tagur87 on GitHub both reported issues with long URLs
that were exceeding the 8192 byte large_header_buffer_size setting,
which resulted in a HTTP 431 error (Request Header Fields Too Large).

This can be resolved in the code by updating the following line in
src/nxt_router.c::nxt_router_conf_create()

    skcf->large_header_buffer_size = 8192;

However, requiring users to modify unit and install custom versions is
less than ideal. We could increase the value, but to what?

This commit takes the option of allowing the user to set this option in
their config by making large_header_buffer_size a valid configuration
setting.

large_header_buffer_size is already set by the configuration system in
nxt_router.c it just isn't set as a valid config option in
nxt_conf_validation.c

With this change users can set this option in their config if required
by the following

    "settings": {
        "http": {
            "large_header_buffer_size": 16384
        }
    },

It retains its default value of 8192 bytes if this is not set.

With this commit, without the above setting or too low a value, with a
long URL you get a 431 error. With the above setting set to a large
enough value, the request is successful.

NOTE: This setting really determines the maximum size of any single
      header _value_. Also, unit will try and place multiple values
      into a buffer _if_ they fully fit.

NOTE: This is being released as undocumented and subject to change as it
      exposes internal workings of unit.

Closes: <https://github.com/nginx/unit/issues/521>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2022-12-13 13:36:30 +00:00
2022-01-10 16:07:31 +03:00
2022-12-03 18:11:14 +00:00
2022-05-03 12:41:36 +02:00
2020-09-18 19:37:56 +01:00
2022-09-13 09:30:30 +01:00
2022-10-03 14:16:44 +01:00
2022-09-13 09:27:13 +01:00
2017-09-06 18:26:37 +03:00
2022-02-15 18:21:10 +03:00
2022-11-24 15:06:54 +00:00
2022-09-19 11:59:59 +01:00

NGINX Unit

Universal Web App Server

NGINX Unit Logo

NGINX Unit is a lightweight and versatile open-source server that has three core capabilities:

  • it is an HTTP reverse proxy,
  • a web server for static media assets,
  • and an application server that runs code in seven languages.

We are building a universal tool that 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 building block for any web architecture regardless of its complexity, from enterprise-scale deployments to your pet's homepage.

Unit's 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 docker.io/nginx/unit

For a description of image tags, see the docs.

Amazon Linux, Fedora, RedHat

$ curl -sL 'https://unit.nginx.org/_downloads/setup-unit.sh' | sudo -E bash
# yum install unit

For details and available language packages, see the docs.

Debian, Ubuntu

$ curl -sL 'https://unit.nginx.org/_downloads/setup-unit.sh' | sudo -E bash
# apt install unit

For details and available language packages, see the docs.

Running a Hello World App

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.

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.

Description
No description provided
Readme 12 MiB
Languages
Shell 63.7%
HTML 36.3%