History log of /unit/docs/changes.xml (Results 1 – 25 of 197)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# 2204:654ec7adbe4f 21-Sep-2022 Zhidao HONG

Status: fixed error in connection statistics.

When proxy is used, the number of accepted connections is not counted,
This also results in the wrong number of active connections.


# 2203:6b6b979e8214 18-Sep-2022 Zhidao HONG

HTTP: fixed cookie parsing.

The fixing supports the cookie value with the '=' character.

This is related to #756 PR on Github.
Thanks to changxiaocui.


# 2202:29b3edfb613d 19-Sep-2022 Andrei Zeliankou

Version bump.


Revision tags: 1.28.0-1, 1.28.0
# 2197:a9ac98dad105 13-Sep-2022 Andrei Zeliankou

Added version 1.28.0 CHANGES.


# 2196:7009706269f0 13-Sep-2022 Andrei Zeliankou

Reordered changes for 1.28.0 by significance (subjective).


# 2195:8dee71bcf84e 12-Sep-2022 Andrei Zeliankou

Capitalize "HTTP" in "changes.xml" to match common style.


# 2194:0bce50b93a6a 09-Sep-2022 Alex Colomar

Fixed a mutex leak in the C API.

In nxt_unit_create() we could leak a mutex created in
nxt_unit_ctx_init().

This could happen if nxt_unit_ctx_init() succeeded but later on we
bailed out of nxt_unit

Fixed a mutex leak in the C API.

In nxt_unit_create() we could leak a mutex created in
nxt_unit_ctx_init().

This could happen if nxt_unit_ctx_init() succeeded but later on we
bailed out of nxt_unit_create(), we would destroy the mutex created in
nxt_unit_create() but not the one created in nxt_unit_ctx_init().

Reorder things so that we do the call to nxt_unit_create() after all the
other checks so if it fails we don't leak the mutex it created.

Co-developed-by: Andrew Clayton <a.clayton@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@f5.com>
Signed-off-by: Alex Colomar <a.colomar@f5.com>

show more ...


# 2188:a23ce83e19dd 05-Sep-2022 Andrei Zeliankou

Fixed minor issues in "changes.xml".


# 2185:2227bdbb3c89 29-Aug-2022 Valentin Bartenev

Implemented basic statistics API.


# 2183:5f7bba4cc968 30-Aug-2022 Andrew Clayton

Ruby: prevented a segfault on receiving SIGINT (^C).

As was reported[0] by @travisbell on GitHub, if running unit from the
terminal in the foreground when hitting ^C to exit it, the ruby
application

Ruby: prevented a segfault on receiving SIGINT (^C).

As was reported[0] by @travisbell on GitHub, if running unit from the
terminal in the foreground when hitting ^C to exit it, the ruby
application processes would segfault if they were using threads.

It's not 100% clear where the actual problem lies, but it _looks_ like
it may be in ruby.

The simplest way to deal with this for now is to just ignore SIGINT in
the ruby application processes. Unit will still receive and handle it,
cleanly shutting everything down.

For people who want to handle SIGINT in their ruby application running
under unit they can still trap SIGINT and it will override the ignore.

[0]: https://github.com/nginx/unit/issues/562#issuecomment-1223229585

Closes: https://github.com/nginx/unit/issues/562

show more ...


# 2181:bb0bd4a80464 28-Jul-2022 Alejandro Colomar

Disallowed abstract unix socket syntax in non-Linux systems.

The previous commit added/fixed support for abstract Unix domain sockets
on Linux with a leading '@' or '\0'. To be consistent in all pl

Disallowed abstract unix socket syntax in non-Linux systems.

The previous commit added/fixed support for abstract Unix domain sockets
on Linux with a leading '@' or '\0'. To be consistent in all platforms,
treat those prefixes as markers for abstract sockets in all platforms,
and fail if abstract sockets are not supported by the platform.

That will avoid mistakes when copying a config file from a Linux system
and using it in non-Linux, which would surprisingly create a normal socket.

show more ...


# 2179:8686f63a2228 28-Jul-2022 Alejandro Colomar

Fixed support for abstract Unix sockets.

Unix domain sockets are normally backed by files in the
filesystem. This has historically been problematic when closing
and opening again such sockets, sinc

Fixed support for abstract Unix sockets.

Unix domain sockets are normally backed by files in the
filesystem. This has historically been problematic when closing
and opening again such sockets, since SO_REUSEADDR is ignored for
Unix sockets (POSIX left the behavior of SO_REUSEADDR as
implementation-defined, and most --if not all-- implementations
decided to just ignore this flag).

Many solutions are available for this problem, but all of them
have important caveats:

- unlink(2) the file when it's not needed anymore.

This is not easy, because the process that controls the fd may
not be the same process that created the file, and may not have
file permissions to remove it.

Further solutions can be applied to that caveat:

- unlink(2) the file right after creation.

This will remove the pathname from the filesystem without
closing the socket (it will continue to live until the last fd
is closed). This is not useful for us, since we need the
pathname of the socket as its interface.

- chown(2) or chmod(2) the directory that contains the socket.

For removing a file from the filesystem, a process needs
write permissions in the containing directory. We could
put sockets in dummy directories that can be chown(2)ed to
nobody. This could be dangerous, though, as we don't control
the socket names. It is our users who configure the socket
name in their configuration, and so it's easy that they don't
understand the many implications of not chosing an appropriate
socket pathname. A user could unknowingly put the socket in a
directory that is not supposed to be owned by user nobody, and
if we blindly chown(2) or chmod(2) the directory, we could be
creating a big security hole.

- Ask the main process to remove the socket.

This would require a very complex communication mechanism with
the main process, which is not impossible, but let's avoid it
if there are simpler solutions.

- Give the child process the CAP_DAC_OVERRIDE capability.

That is one of the most powerful capabilities. A process with
that capability can be considered root for most practical
aspects. Even if the capability is disabled for most of the
lifetime of the process, there's a slight chance that a
malicious actor could activate it and then easily do serious
damage to the system.

- unlink(2) the file right before calling bind(2).

This is dangerous because another process (for example, another
running instance of unitd(8)), could be using the socket, and
removing the pathname from the filesystem would be problematic.
To do this correctly, a lot of checks should be added before the
actual unlink(2), which is error-prone, and difficult to do
correctly, and atomically.

- Use abstract-namespace Unix domain sockets.

This is the simplest solution, as it only requires accepting a
slightly different syntax (basically a @ prefix) for the socket
name, to transform it into a string starting with a null byte
('\0') that the kernel can understand. The patch is minimal.

Since abstract sockets live in an abstract namespace, they don't
create files in the filesystem, so there's no need to remove
them later. The kernel removes the name when the last fd to it
has been closed.

One caveat is that only Linux currently supports this kind of
Unix sockets. Of course, a solution to that could be to ask
other kernels to implement such a feature.

Another caveat is that filesystem permissions can't be used to
control access to the socket file (since, of course, there's no
file). Anyone knowing the socket name can access to it. The
only method to control access to it is by using
network_namespaces(7). Since in unitd(8) we're using 0666 file
sockets, abstract sockets should be no more insecure than that
(anyone can already read/write to the listener sockets).

- Ask the kernel to implement a simpler way to unlink(2) socket
files when they are not needed anymore. I've suggested that to
the <linux-fsdevel@vger.kernel.org> mailing list, in:
<lore.kernel.org/linux-fsdevel/0bc5f919-bcfd-8fd0-a16b-9f060088158a@gmail.com/T>

In this commit, I decided to go for the easiest/simplest solution,
which is abstract sockets. In fact, we already had partial
support. This commit only fixes some small bug in the existing
code so that abstract Unix sockets work:

- Don't chmod(2) the socket if it's an abstract one.

This fixes the creation of abstract sockets, but doesn't make them
usable, since we produce them with a trailing '\0' in their name.
That will be fixed in the following commit.

This closes #669 issue on GitHub.

show more ...


# 2174:a7fb5d8a9590 17-Feb-2022 Max Romanov

Fixing isolated process PID manipulation.

Registering an isolated PID in the global PID hash is wrong
because it can be duplicated. Isolated processes are stored only
in the children list until the

Fixing isolated process PID manipulation.

Registering an isolated PID in the global PID hash is wrong
because it can be duplicated. Isolated processes are stored only
in the children list until the response for the WHOAMI message is
processed and the global PID is discovered.

To remove isolated siblings, a pointer to the children list is
introduced in the nxt_process_init_t struct.

This closes #633 issue on GitHub.

show more ...


# 2173:b4797a4fcb2d 04-Aug-2022 Alejandro Colomar

Put changes entry in the correct position.


# 2166:64a3527f65ad 28-Jul-2022 Zhidao HONG

Log: customizable access log format.


# 2164:52fbf5e84a42 28-Jul-2022 Zhidao HONG

Ruby: fixed segfault on SIGTERM signal.

This closes #562 issue on GitHub.


# 2163:67d2d679509e 09-Jun-2022 Alejandro Colomar

Ruby: fixed contents of SCRIPT_NAME.

Having the basename of the script pathname was incorrect. While
we don't have something more accurate, the best thing to do is to
have it empty (which should be

Ruby: fixed contents of SCRIPT_NAME.

Having the basename of the script pathname was incorrect. While
we don't have something more accurate, the best thing to do is to
have it empty (which should be the right thing most of the time).

This closes #715 issue on GitHub.

The bug was introduced in git commit
0032543fa65f454c471c968998190b027c1ff270
'Ruby: added the Rack environment parameter "SCRIPT_NAME".'.

show more ...


# 2162:fd2a3c0ad344 26-Jul-2022 Alejandro Colomar

Fixed line removed by accident.

When fixing conflicts in the changelog, a line was removed by accident.

Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>


# 2161:f8e608f69800 27-Feb-2022 Alejandro Colomar

Supporting UNIX sockets in address matching.

This closes #645 issue on GitHub.

(Also moved a changelog line that was misplaced in a previous commit.)


# 2158:bbc15554fb36 06-May-2022 Andrew Clayton

Var: added a $dollar variable that translates to a '$'.

Allow $dollar (or ${dollar}) to translate to a literal $ to allow
support for sub-delimiters in URIs.

It is possible to have URLs like

htt

Var: added a $dollar variable that translates to a '$'.

Allow $dollar (or ${dollar}) to translate to a literal $ to allow
support for sub-delimiters in URIs.

It is possible to have URLs like

https://example.com/path/15$1588/9925$2976.html

and thus it would be useful to be able to specify them in various bits
of the unit config such as the location setting.

However this hadn't been possible due to $ being used to denote
variables for substitution. E.g $host.

As was noted in the below GitHub issue it was suggested by @VBart to
use $sign to represent a literal $, however I feel $dollar is more
appropriate so we have a variable named after the thing it represents,
also @tippexs found[0] that &dollar is used in HTML to represent a $, so
there is some somewhat related precedent.

(The other idea to use $$ was rejected in my original pull-request[1]
for this issue.)

This means the above URL could be specified as

https://example.com/path/15${dollar}1588/9925${dollar}2976.html

in the unit config.

This is done by adding a variable called 'dollar' which is loaded into
the variables hash table which translates into a literal $.

This is then handled in nxt_var_next_part() where variables are parsed
for lookup and $dollar is set for substitution by a literal '$'. Actual
variable substitution happens in nxt_var_query_finish().

[0]: https://github.com/nginx/unit/pull/693#issuecomment-1130412323
[1]: https://github.com/nginx/unit/pull/693

Closes: https://github.com/nginx/unit/issues/675

show more ...


# 2149:7a53238e050d 13-Jul-2022 Zhidao HONG

HTTP: added more variables.

This commit adds the following variables:
$remote_addr, $time_local, $request_line, $status,
$body_bytes_sent, $header_referer, $header_user_agent.


# 2147:7bf58b1b18c4 13-Jul-2022 Zhidao HONG

Var: dynamic variables support.

This commit adds the variables $arg_NAME, $header_NAME, and $cookie_NAME.


# 2145:ee1e319c8ed8 24-Apr-2022 Timo Stark

Increased readtimeout for configuration endpoint.

Closes: <https://github.com/nginx/unit/issues/676>


# 2137:96f3ac16391b 06-Jun-2022 Alejandro Colomar

Static: Fixed finding the file extension.

The code for finding the extension made a few assumptions that are
no longer true. It didn't account for pathnames that didn't
contain '/', including the e

Static: Fixed finding the file extension.

The code for finding the extension made a few assumptions that are
no longer true. It didn't account for pathnames that didn't
contain '/', including the empty string, or the NULL string. That
code was used with "share", which always had a '/', but now it's
also used with "index", which should not have a '/' in it.

This fix works by limiting the search to the beginning of the
string, so that if no '/' is found in it, it doesn't continue
searching before the beginning of the string.

This also happens to work for NULL. It is technically Undefined
Behavior, as we rely on `NULL + 0 == NULL` and `NULL - NULL == 0`.
But that is the only sane behavior for an implementation, and all
existing POSIX implementations will Just Work for this code.

Relying on this UB is useful, because we don't need to add an
explicit check for NULL, and therefore we have faster code.
Although the current code can't have a NULL, I expect that when we
add support for variables in the index, it will be NULL in some
cases.

Link: <https://stackoverflow.com/q/67291052/6872717>

The same code seems to be defined behavior in C++, which normally
will share implementation in the compiler for these cases, and
therefore it is really unlikely to be in trouble.

Link: <https://stackoverflow.com/q/59409034/6872717>

show more ...


# 2135:3e77e025384d 20-Jun-2022 Konstantin Pavlov

Switched changelogs to packaging alias instead of personal emails.


12345678