Because the configuration values were read from the listener's configuration,
an established WebSocket connection was unable to work properly (i. e. stuck)
if the listener was removed. The correct source of configuration values is the
request config joint.
This is related to issue #581 on GitHub.
Since the "pass" option supports both strings and variables, a generic
nxt_var_t structure can be used in the configuration phase, and the "name"
field in actions is redundant.
No functional changes.
This commit introduces the replacement of the client address based on the value
of a specified HTTP header. This is intended for use when Unit is placed
behind a reverse proxy like nginx or a CDN.
You must specify the source addresses of the trusted proxies. This can be
accomplished with any valid IP pattern supported by Unit's match block:
["10.0.0.1", "10.4.0.0/16", "!192.168.1.1"]
The feature is configured per listener.
The client address replacement functionality only operates when there is a
source IP match and the specified header is present. Typically this would be
an 'X-Forwarded-For' header.
{
"listeners": {
"127.0.0.1:8080": {
"client_ip": {
"header": "X-Forwarded-For",
"source": [
"10.0.0.0/8"
]
},
"pass": "applications/my_app"
},
}
}
If a request occurs and Unit receives a header like below:
"X-Forwarded-For: 84.123.23.23"
By default, Unit trusts the last rightmost IP in the header, so REMOTE_ADDR
will be set to 84.123.23.23 if the connection originated from 10.0.0.0/8.
If Unit runs behind consecutive reverse proxies and receives a header similar
to the following:
"X-Forwarded-For: 84.123.23.23, 10.0.0.254"
You will need to enable "recursive" checking, which walks the header from
last address to first and chooses the first non-trusted address it finds.
{
"listeners": {
"127.0.0.1:8080": {
"client_ip": {
"header": "X-Forwarded-For",
"source": [
"10.0.0.0/8"
]
"recursive": true,
},
"pass": "applications/my_app"
},
}
}
If a connection from 10.0.0.0/8 occurs, the chain is walked. Here, 10.0.0.254
is also a trusted address so the client address will be replaced with
84.123.23.23.
If all IP addresses in the header are trusted, the client address is set to
the first address in the header:
If 10.0.0.0/8 is trusted and "X-Forwarded-For: 10.0.0.3, 10.0.0.2, 10.0.0.1",
the client address will be replaced with 10.0.0.3.
A crash would occur when the router tried to match an
against an empty address pattern array.
The following configuration was used to reproduce the
issue:
{
"listeners": {
"127.0.0.1:8082": {
"pass": "routes"
}
},
"routes": [
{
"match": {
"source": []
},
"action": {
"return": 200
}
}
]
}
In the case that routes or upstreams is empty and the pass option is a variable.
If the resolved pass is routes or upstreams, a segment error occurred.
When processing a restart request, the router sends a QUIT message to all
existing processes of the application. Then, a new shared application port is
created to ensure that new requests won't be handled by the old processes of
the application.
When a client sends no SNI is a common situation. But currently the server
processes it as an error and returns SSL_TLSEXT_ERR_ALERT_FATAL causing
termination of a current TLS session. The problem occurs if configuration has
more than one certificate bundle in a listener.
This fix changes the return code to SSL_TLSEXT_ERR_OK and the log level of a
message.
To support TLS sessions, Unit uses the OpenSSL built-in session cache; the
cache_size option defines the number sessions to store. To disable the feather,
the option must be zero.
Unit's ASGI implementation creates a new event loop to run an application for
each thread since 542b5b8c0647. This may cause unexpected exceptions or
strange bugs if asyncio synchronisation primitives are initialised before the
application starts (e.g. globally).
Although the approach with a new event loop for the main thread is consistent
and helps to prepare the application to run in multiple threads, it can be a
source of pain for people who just want to run single-threaded ASGI
applications in Unit.
This is related to #560 issue on GitHub.
An ASGI application can cancel the Future object returned by the receive()
call. In this case, Unit's ASGI implementation should not call set_result()
because the Future is already handled. In particular, the Starlette framework
was noted to cancel the received Future.
This patch adds a done() check for the Future before attempting a set_result().
This is related to #564 issue on GitHub.
The receive() call never blocks for a GET request and always returns the same
empty body message. The Starlette framework creates a separate task when
receive() is called in a loop until an 'http.disconnect' message is received.
The 'http.disconnect' message was previously issued after the response header
had been sent. However, the correct behavior is to respond with
'http.disconnect' after sending the response is complete.
This closes#564 issue on GitHub.
A new application thread port message can be processed in the router after the
application is removed from the router. Assertion for this case is replaced by
a condition to store the new thread port until receiving the stop notification
from the application process.
This feature allows one to specify blocks of code that are called when certain
lifecycle events occur. A user configures a "hooks" property on the app
configuration that points to a script. This script will be evaluated on boot
and should contain blocks of code that will be called on specific events.
An example of configuration:
{
"type": "ruby",
"processes": 2,
"threads": 2,
"user": "vagrant",
"group": "vagrant",
"script": "config.ru",
"hooks": "hooks.rb",
"working_directory": "/home/vagrant/unit/rbhooks",
"environment": {
"GEM_HOME": "/home/vagrant/.ruby"
}
}
An example of a valid "hooks.rb" file follows:
File.write("./hooks.#{Process.pid}", "hooks evaluated")
on_worker_boot do
File.write("./worker_boot.#{Process.pid}", "worker booted")
end
on_thread_boot do
File.write("./thread_boot.#{Process.pid}.#{Thread.current.object_id}",
"thread booted")
end
on_thread_shutdown do
File.write("./thread_shutdown.#{Process.pid}.#{Thread.current.object_id}",
"thread shutdown")
end
on_worker_shutdown do
File.write("./worker_shutdown.#{Process.pid}", "worker shutdown")
end
This closes issue #535 on GitHub.
When the textual representation of an IPv6 nxt_sockaddr_t was being
generated, a crash would occur if the address had a full IPv6 form:
f607:7403:1e4b:6c66:33b2:843f:2517:da27
This was caused by a variable that tracks the location of a
collapsed group ("::") that was not set to a sane default. When
the address was generated, a group would be inserted when
it was not necessary, thus causing an overflow.
This closes#481 issue on GitHub.
In rare cases, when the destination process had finished running but no
notification of this was received yet, send could fail with an error, and the
send message structure with file descriptors could leak.
The leakage was periodically reproduced by respawn tests on FreeBSD 12.
If an exception was raised with a backtrace of zero length, the
nxt_ruby_exception_log() routine would return without logging the
exception class and message. This commit fixes the issue.
Because of the incorrect 'last' field assignment, multiple listeners with
a TLS certificate did not initialize properly, which caused a router crash
while establishing a connection.
Test with multiple TLS listeners added.
The issue was introduced in the c548e46fe516 commit.
This closes#561 issue on GitHub.
The patch removes the "files" section from package.json to avoid future issues
with missing files. For package testing purposes, 'npm pack' is used instead
of plain 'tar' to simulate packaging more accurately.
To perform various configuration operations on SSL_CTX, OpenSSL provides
SSL_CONF_cmd(). Specifically, to configure ciphers for a listener,
"CipherString" and "Ciphersuites" file commands are used:
https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
This feature can be configured in the "tls/conf_commands" section.
A crash was caused by an incorrect timer handler nxt_h1p_idle_timeout() if
SSL_shutdown() returned SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE.
The flag SSL_RECEIVED_SHUTDOWN is used to avoid getting SSL_ERROR_WANT_READ, so
the server won't wait for a close notification from a client.
For SSL_ERROR_WANT_WRITE, a correct timer handler is set up.
This patch fixes a possible race between the nxt_router_conf_wait() and
nxt_router_listen_socket_release() function calls and improves the 7f1b2eaa2d58
commit fix.
Ruby 3.0 deprecated rb_cData with the intention to remove it in release 3.1.
This commit changes references of rb_cData to rb_cObject. This was done so we
can support distributions that package Ruby 3.0, such as Fedora 34.
We also need to call rb_undef_alloc_func because we're no longer deriving from
rb_cData. This prevents unnecessary allocations.
See:
https://docs.ruby-lang.org/en/3.0.0/doc/extension_rdoc.html
"It is recommended that klass derives from a special class called Data
(rb_cData) but not from Object or other ordinal classes. If it doesn't,
you have to call rb_undef_alloc_func(klass)."
When an invalid TLS configuration is applied (such as the conf_commands
feature), nxt_cert_store_get() creates a buffer to send a certificate request
to the main process and adds its default completion handler to an asynchronous
queue to free the allocated buffer. However, if configuration fails,
nxt_router_conf_error() removes the memory pool used to allocate the buffer,
causing a crash when the completion handler is dispatched.
Assertion "src/nxt_buf.c:208 assertion failed: data == b->parent" is triggered
when is NXT_DEBUG enabled in the configure script.
This patch uses a reference counter to retain the memory pool and redefines the
completion handler to free the buffer before releasing the memory pool.
Listen socket is actually closed in the instant timer handler. This patch moves
the "configuration has been applied" notification to the timer handler to avoid
a situation when the user gets the response from the controller, but the listen
socket is still open in the router.
Also added stubs for Server.address()
This was done to prevent crashes in some popular frameworks like express
Supports both CommonJS and the new ES Modules system syntax e.g:
app.js:
const http = require('http')
app.mjs:
import http from "http"
Usage on Node 14.16.x and higher:
{
"type": "external",
"processes": {"spare": 0},
"working_directory": '/project',
"executable": "/usr/bin/env",
"arguments": [
"node",
"--loader",
"unit-http/require_shim.mjs"
"--require",
"unit-http/require_shim",
"app.js"
]
}
Usage on Node 14.15.x and lower:
{
"type": "external",
"processes": {"spare": 0},
"working_directory": '/project',
"executable": "/usr/bin/env",
"arguments": [
"node",
"--require",
"unit-http/require_shim",
"app.js"
]
}
The "auto_globals_jit" PHP option postponed the initialization of the $_SERVER
global variable until the script using it had been loaded (e. g. via the
"include" expression). As a result, nxt_php_register_variables() could be
called after fastcgi_finish_request() had finished the request and nulled
ctx->req, which thus caused a segmentation fault.
