Home
last modified time | relevance | path

Searched hist:4 (Results 126 – 150 of 326) sorted by relevance

12345678910>>...14

/unit/src/test/
H A Dnxt_unit_app_test.cdiff 2476:cb8c2da2afd9 Mon May 22 00:37:00 UTC 2023 Alejandro Colomar <alx@nginx.com> Tests: fixed incorrect pointer assignment.

If we don't update the pointer before copying the request body, then we
get the behavior shown below. After this patch, "foo\n" is rightly
appended at the end of the response body.

Request:

"GET / HTTP/1.1\r\nHost: _\nContent-Length: 4\n\nfoo\n"

Response body:

"""
Hello world!
foo
est data:
Method: GET
Protocol: HTTP/1.1
Remote addr: 127.0.0.1
Local addr: 127.0.0.1
Target: /
Path: /
Fields:
Host: _
Content-Length: 4
Body:
"""

Fixes: 1bb22d1e922c ("Unit application library.")
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
diff 2476:cb8c2da2afd9 Mon May 22 00:37:00 UTC 2023 Alejandro Colomar <alx@nginx.com> Tests: fixed incorrect pointer assignment.

If we don't update the pointer before copying the request body, then we
get the behavior shown below. After this patch, "foo\n" is rightly
appended at the end of the response body.

Request:

"GET / HTTP/1.1\r\nHost: _\nContent-Length: 4\n\nfoo\n"

Response body:

"""
Hello world!
foo
est data:
Method: GET
Protocol: HTTP/1.1
Remote addr: 127.0.0.1
Local addr: 127.0.0.1
Target: /
Path: /
Fields:
Host: _
Content-Length: 4
Body:
"""

Fixes: 1bb22d1e922c ("Unit application library.")
Reviewed-by: Andrew Clayton <a.clayton@nginx.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
H A Dnxt_tests.hdiff 1975:6a47cab8f271 Tue Oct 26 12:43:00 UTC 2021 Valentin Bartenev <vbart@nginx.com> Custom implementation of Base64 decoding function.

Compared to the previous implementation based on OpenSSL, the new implementation
has these advantages:

1. Strict and reliable detection of invalid strings, including strings with
less than 4 bytes of garbage at the end;

2. Allows to use Base64 strings without '=' padding.
/unit/pkg/deb/debian.module/
H A Dcontrol-noarch.indiff 2036:7e018fce7985 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
diff 2020:f8e0a0b7ffb9 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
H A Dcontrol.indiff 2036:7e018fce7985 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
diff 2020:f8e0a0b7ffb9 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
/unit/test/python/unicode/
H A Dwsgi.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
/unit/src/
H A Dnxt_external.cdiff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
diff 1320:4e70411b9842 Tue Dec 24 15:04:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Adding "limits/shm" configuration validation and parsing.
diff 977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
H A Dnxt_clone.hdiff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
H A Dnxt_thread_pool.cdiff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_work_queue.cdiff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_array.cdiff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
H A Dnxt_clone.cdiff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2629:116cb969f351 Wed Jan 24 18:01:00 UTC 2024 Andrew Clayton <a.clayton@nginx.com> Isolation: Use an appropriate type for storing uid/gids

Andrei reported an issue on arm64 where he was seeing the following
error message when running the tests

2024/01/17 18:32:31.109 [error] 54904#54904 "gidmap" field has an entry with "size": 1, but for unprivileged unit it must be 1.

This error message is guarded by the following if statement

if (nxt_slow_path(m.size > 1)

Turns out size was indeed > 1, in this case it was 289356276058554369,
m.size is defined as a nxt_int_t, which on arm64 is actually 8 bytes,
but was being printed as a signed int (4 bytes) and by chance/undefined
behaviour comes out as 1.

But why is size so big? In this case it should have just been 1 with a
config of

'gidmap': [{'container': 0, 'host': os.getegid(), 'size': 1}],

This is due to nxt_int_t being 64bits on arm64 but using a conf type of
NXT_CONF_MAP_INT which means in nxt_conf_map_object() we would do (using
our m.size variable as an example)

ptr = nxt_pointer_to(data, map[i].offset);
...
ptr->i = num;

Where ptr is a union pointer and is now pointing at our m.size

Next we set m.size to the value of num (which is 1 in this case), via
ptr->i where i is a member of that union of type int.

So here we are setting a 64bit memory location (nxt_int_t on arm64)
through a 32bit (int) union alias, this means we are only setting the
lower half (4) of the bytes.

Whatever happens to be in the upper 4 bytes will remain, giving us our
exceptionally large value.

This is demonstrated by this program

#include <stdio.h>
#include <stdint.h>

int main(void)
{
int64_t num = -1; /* All 1's in two's complement */
union {
int32_t i32;
int64_t i64;
} *ptr;

ptr = (void *)&num;

ptr->i32 = 1;
printf("num : %lu / %ld\n", num, num);
ptr->i64 = 1;
printf("num : %ld\n", num);

return 0;
}
$ make union-32-64-issue
cc union-32-64-issue.c -o union-32-64-issue
$ ./union-32-64-issue
num : 18446744069414584321 / -4294967295
num : 1

However that is not the only issue, because the members of
nxt_clone_map_entry_t were specified as nxt_int_t's on the likes of
x86_64 this would be a 32bit signed integer. However uid/gids on Linux
at least are defined as unsigned integers, so a nxt_int_t would not be
big enough to hold all potential values.

We could make the nxt_uint_t's but then we're back to the above union
aliasing problem.

We could just set the memory for these variables to 0 and that would
work, however that's really just papering over the problem.

The right thing is to use a large enough sized type to store these
things, hence the previously introduced nxt_cred_t. This is an int64_t
which is plenty large enough.

So we switch the nxt_clone_map_entry_t structure members over to
nxt_cred_t's and use NXT_CONF_MAP_INT64 as the conf type, which then
uses the right sized union member in nxt_conf_map_object() to set these
variables.

Reported-by: Andrei Zeliankou <zelenkov@nginx.com>
Reviewed-by: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.

Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9,
or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.

Found with:

$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
H A Dnxt_main.cdiff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring.
The cycle has been renamed to the runtime.
H A Dnxt_work_queue.hdiff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.

Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9,
or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.

Found with:

$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
diff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring.
The cycle has been renamed to the runtime.
diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
H A Dnxt_upstream_round_robin.cdiff 20:4dc92b438f58 Thu Mar 09 15:03:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Processes refactoring.
The cycle has been renamed to the runtime.
H A Dnxt_mp.cdiff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.

Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9,
or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.

Found with:

$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
diff 832:4f5daf367ff7 Sat Nov 10 04:38:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Fixed "freed pointer is out of pool" alerts.

The issue was caused by misplacement of allocated blocks in rbtree due
to broken comparison function if the distance between two allocations
did not fit into intptr_t. As the result, nxt_mp_free() could have
failed to find the allocation.

In particular, it was mostly observed when Unit was compiled with
musl C library on 32-bits systems.

This closes #118 issue on GitHub.
diff 147:4ed5e68f196c Wed Jul 12 17:57:00 UTC 2017 Valentin Bartenev <vbart@nginx.com> Fixed style and building with NXT_DEBUG_MEMORY after 3578a7b7ace4.
/unit/src/java/nginx/unit/
H A DRequest.java977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
/unit/test/python/lifespan/empty/
H A Dasgi.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
/unit/test/
H A Dtest_python_isolation_chroot.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
H A Dtest_routing.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
diff 1775:4b4991514356 Thu Jan 14 03:04:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: added missing checks for configuration results.
diff 1478:4a68052b8b4d Fri May 15 03:21:00 UTC 2020 Andrei Zeliankou <zelenkov@nginx.com> Tests: added test for encoding in the "pass" option.
diff 1377:4a45d0d5bd51 Tue Mar 03 17:37:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Improved validation of the "action" object.

Now it enforces the mutual exclusivity of "pass", "proxy", and "share" options.
diff 1370:4c19e4145070 Thu Feb 27 01:37:00 UTC 2020 Andrei Zeliankou <zelenkov@nginx.com> Tests: added test with invalid IPv6 address in routing block.
diff 1110:4ca6df50b4d4 Wed Jul 24 10:47:00 UTC 2019 Axel Duch <axel.duch@nginx.com> Added routing based on request scheme.

Scheme matches exact string “http” or “https”.
/unit/pkg/deb/debian/
H A Dcontrol.indiff 2036:7e018fce7985 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
diff 2020:f8e0a0b7ffb9 Wed Dec 01 06:01:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: adjusted debhelper minimal version for Debian/Ubuntu.

Forgotten in 199a11eceb3c.

While here, Standards-Version increased to 4.1.4 (matches Ubuntu 18.04
as the oldest supported distro).
/unit/src/java/nginx/unit/websocket/
H A DWsRemoteEndpointImplBase.javadiff 2078:0996dd223cdd Sat Dec 18 23:58:00 UTC 2021 Alejandro Colomar <alx.manpages@gmail.com> Fixed indentation.

Some lines (incorrectly) had an indentation of 3 or 5, or 7 or 9,
or 11 or 13, or 15 or 17 spaces instead of 4, 8, 12, or 16. Fix them.

Found with:

$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ ]';
$ find src -type f | xargs grep -n '^ [^ *]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
$ find src -type f | xargs grep -n '^ [^ +]';
$ find src -type f | xargs grep -n '^ [^ *+]';
/unit/src/java/
H A Dnxt_jni_Request.c977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.
/unit/test/unit/
H A Dlog.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
/unit/test/unit/check/
H A Dunix_abstract.pydiff 2330:4b1f175f9c88 Tue Feb 21 17:21:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: switched to using f-strings.

Previously, it was necessary to support older versions of Python for
compatibility. F-strings were released in Python 3.6. Python 3.5 was
marked as unsupported by the end of 2020, so now it's possible to start
using f-strings safely for better readability and performance.
/unit/src/ruby/
H A Dnxt_ruby.cdiff 2608:2091b078cdf6 Mon Oct 23 13:24:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Ruby: Handle response field arrays

@xeron on GitHub reported an issue whereby with a Rails 7.1 application
they were getting the following error

2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Wrong header entry 'value' from application
2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Failed to run ruby script

After some back and forth debugging it turns out rack was trying to send
back a header comprised of an array of values. E.g

app = Proc.new do |env|
["200", {
"Content-Type" => "text/plain",
"X-Array-Header" => ["Item-1", "Item-2"],
}, ["Hello World\n"]]
end

run app

It seems this became a possibility in rack v3.0[0]

So along with a header value type of T_STRING we need to also allow
T_ARRAY.

If we get a T_ARRAY we need to build up the header field using the given
values.

E.g

"X-Array-Header" => ["Item-1", "", "Item-3", "Item-4"],

becomes

X-Array-Header: Item-1; ; Item-3; Item-4

[0]: <https://github.com/rack/rack/blob/main/UPGRADE-GUIDE.md?plain=1#L26>

Reported-by: Ivan Larionov <xeron.oskom@gmail.com>
Closes: <https://github.com/nginx/unit/issues/974>
Link: <https://github.com/nginx/unit/pull/998>
Tested-by: Timo Stark <t.stark@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2608:2091b078cdf6 Mon Oct 23 13:24:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Ruby: Handle response field arrays

@xeron on GitHub reported an issue whereby with a Rails 7.1 application
they were getting the following error

2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Wrong header entry 'value' from application
2023/10/22 20:57:28 [error] 56#56 [unit] #8: Ruby: Failed to run ruby script

After some back and forth debugging it turns out rack was trying to send
back a header comprised of an array of values. E.g

app = Proc.new do |env|
["200", {
"Content-Type" => "text/plain",
"X-Array-Header" => ["Item-1", "Item-2"],
}, ["Hello World\n"]]
end

run app

It seems this became a possibility in rack v3.0[0]

So along with a header value type of T_STRING we need to also allow
T_ARRAY.

If we get a T_ARRAY we need to build up the header field using the given
values.

E.g

"X-Array-Header" => ["Item-1", "", "Item-3", "Item-4"],

becomes

X-Array-Header: Item-1; ; Item-3; Item-4

[0]: <https://github.com/rack/rack/blob/main/UPGRADE-GUIDE.md?plain=1#L26>

Reported-by: Ivan Larionov <xeron.oskom@gmail.com>
Closes: <https://github.com/nginx/unit/issues/974>
Link: <https://github.com/nginx/unit/pull/998>
Tested-by: Timo Stark <t.stark@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 1738:4a7bb9e7678a Mon Dec 07 18:17:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Ruby: fixed crash on thread start.

Ruby threads need to be created with GVL; otherwise, an attempt to access
locked resources may occur, causing a crash.

The issue was occasionally reproduced on Ubuntu 18.04 with Ruby 2.5.1
while running test_ruby_application_threads.
diff 1532:4b4d0c3ce94b Thu Jul 30 23:21:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Isolation: fixed the generation of mounts table.

Since the introduction of rootfs feature, some language modules
can't be configured multiple times.

Now the configure generates a separate nxt_<module>_mounts.h for
each module compiled.
diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
diff 1320:4e70411b9842 Tue Dec 24 15:04:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Adding "limits/shm" configuration validation and parsing.
diff 977:4f9268f27b57 Thu Feb 28 15:02:00 UTC 2019 Max Romanov <max.romanov@gmail.com> Introducing Java Servlet Container beta.

12345678910>>...14