/unit/src/test/ |
H A D | nxt_unit_app_test.c | 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> 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 D | nxt_tests.h | diff 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 D | control-noarch.in | diff 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 D | control.in | diff 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 D | wsgi.py | diff 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 D | nxt_external.c | 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.
|
H A D | nxt_clone.h | 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 *)#
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 *)#
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 *)#
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 D | nxt_thread_pool.c | diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
|
H A D | nxt_work_queue.c | diff 4:76c63e9b6322 Fri Jan 27 08:35:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Work queues refactoring.
|
H A D | nxt_array.c | diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
|
H A D | nxt_clone.c | 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 *)#
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 *)#
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 *)#
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 D | nxt_main.c | 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.
|
H A D | nxt_work_queue.h | 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 '^ [^ *+]'; 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 D | nxt_upstream_round_robin.c | 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.
|
H A D | nxt_mp.c | 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 '^ [^ *+]'; 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 D | Request.java | 977: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 D | asgi.py | diff 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 D | test_python_isolation_chroot.py | diff 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 D | test_routing.py | diff 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 D | control.in | diff 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 D | WsRemoteEndpointImplBase.java | 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 '^ [^ *+]';
|
/unit/src/java/ |
H A D | nxt_jni_Request.c | 977: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 D | log.py | diff 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 D | unix_abstract.py | diff 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 D | nxt_ruby.c | 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 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.
|