| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
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.
|
|
Found by Clang Static Analyzer.
|
|
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.
|
|
No functional changes.
|
|
No functional changes.
|
|
No functional changes.
|
|
|
|
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.
|
|
This commit fixes a rare crash that can occur when File.write is
called by many threads.
|
|
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.
|
|
A race may occur between the router process restart and the main process
sending a notification to the running controller. For example, a test script
detects the new process and starts performing a smoke test, but the controller
has not yet received the 'remove PID' notification, so the connection to the
router is broken and any attempt to update the configuration will cause an
error.
The solution is to perform several attempts to reconfigure Unit with a short
delay between failures.
|
|
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.
|
|
No functional changes.
|
|
Also minor style changes.
|
|
|
|
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.
|
|
The files loader.js and loader.mjs (introduced in f85b85094541 and 3c551b9721df)
were added to the packaged files list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
