| /unit/test/ |
| H A D | test_node_application.py | diff 2488:55440e02a873 Mon Jun 12 13:16:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Tests: prerequisites checking reworked.
Prerequisites check moved to the module level to simplify class structure.
Discovery and prerequisites checks functions moved to the separate files.
Introduced "require" fixture to provide per-test requirements check.
diff 1848:4bd548074e2c Mon Apr 05 13:03:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
diff 1771:94cf6c5fafbd Wed Jan 13 06:22:00 UTC 2021 Andrei Zeliankou <zelenkov@nginx.com> Tests: style.
diff 1064:75a64629661f Thu May 30 13:46:00 UTC 2019 Andrey Zelenkov <zelenkov@nginx.com> Tests: adjusted skipping tests.
diff 1025:3469f5185562 Tue Apr 09 13:14:00 UTC 2019 Andrey Zelenkov <zelenkov@nginx.com> Tests: simplified module checking.
diff 896:52a353327b3f Tue Dec 25 13:35:00 UTC 2018 Andrey Zelenkov <zelenkov@nginx.com> Tests: test_node_application_write_before_writeHead reworked.
Added res.end() call in application and response status check.
Also, renamed to test_node_application_write_before_write_head.
diff 895:9b261bd95690 Tue Dec 25 13:35:00 UTC 2018 Andrey Zelenkov <zelenkov@nginx.com> Tests: expectedFailure's removed from test_node_application.py.
Also removed alert skip in test_node_application_write_before_writeHead.
Fixes committed in 1340e3539362, 1e008ef94f43, 5df32621af19, dae402cb243f
and 41f561b3a178.
|
| /unit/test/node/write_buffer/ |
| H A D | app.js | diff 1114:6d87da79ec4e Tue Aug 06 13:24:00 UTC 2019 Valentin Bartenev <vbart@nginx.com> Node.js: returning "this" from writeHead() to allow chaining.
In Node.js version 11.10.0 and later, the writeHead() function returns "this".
|
| /unit/src/nodejs/unit-http/ |
| H A D | http_server.js | diff 1132:9ac5b5f33ed9 Tue Aug 20 13:32:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Node.js: introducing websocket support.
diff 1114:6d87da79ec4e Tue Aug 06 13:24:00 UTC 2019 Valentin Bartenev <vbart@nginx.com> Node.js: returning "this" from writeHead() to allow chaining.
In Node.js version 11.10.0 and later, the writeHead() function returns "this".
diff 1021:8884d891d4c7 Mon Apr 01 13:40:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Introducing close event to notify about server stop.
This closes #236 on GitHub.
Thanks to 0xcdcdcdcd.
diff 819:31027fb75905 Wed Oct 24 13:21:00 UTC 2018 Alexander Borisov <alexander.borisov@nginx.com> Node.js: additional type check for response.setHeader value.
|
| /unit/src/wasm/ |
| H A D | nxt_rt_wasmtime.c | 2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
| H A D | nxt_wasm.c | diff 2557:af47f86f96a1 Wed Sep 13 23:37:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Fix multiple successive calls to the request_handler.
When trying to upload files to the luw-upload-reflector demo[0] above a
certain size that would mean Unit would need to make more than two calls
to the request_handler function in the Wasm module we would get the
following error from wasmtime and the upload would stall on the third
call to the request_handler
WASMTIME ERROR: failed to call function [->wasm_request_handler]
error while executing at wasm backtrace:
0: 0x5ce2 - <unknown>!memcpy
1: 0x7df - luw_req_buf_append
at /home/andrew/src/unit-wasm/src/c/libunit-wasm.c:308:14
2: 0x3a1 - luw_request_handler
at /home/andrew/src/unit-wasm/examples/c/luw-upload-reflector.c:110:3
Caused by:
wasm trap: out of bounds memory access
This was due to ->content_off (the offset of where the actual body
content starts in the request structure/memory) being some overly large
value.
This was largely down to me being an idiot!
Before calling the loop that makes the calls to the request_handler we
would calculate the new offset, which is now just the size of the
request structure as we don't re-send all the HTTP meta data and headers
etc. However because this value is in the request structure which is in
the shared memory and we use this same memory for requests and
responses, when we make a response we overwrite this request structure
with the response structure, so our ->content_off is now some wacked out
value when we make the next call to the request_handler.
To fix this we just need to reset ->content_off each time round the
loop.
There's also no point in setting ->nfields to 0, it has the same issue
as above, but doesn't get re-used by the Wasm module anyway.
[0]: <https://github.com/nginx/unit-wasm/blob/main/examples/c/luw-upload-reflector.c>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
| H A D | nxt_wasm.h | 2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2516:fe3712cb1556 Tue Aug 08 13:29:00 UTC 2023 Andrew Clayton <a.clayton@nginx.com> Wasm: Add the core of initial WebAssembly language module support.
This adds the core of runtime WebAssembly[0] support. Future commits
will enable this in the Unit core and expose the configuration.
This introduces a new src/wasm directory for storing this source.
We are initially using Wasmtime[0] as the WebAssembly runtime, however
this has been designed with the ability to use different runtimes in
mind.
src/wasm/nxt_wasm.[ch] is the main interface to Unit.
src/wasm/nxt_rt_wasmtime.c is the Wasmtime runtime support. This is
nicely insulated from any knowledge of internal Unit workings.
Wasmtime is what loads and runs the Wasm modules.
The Wasm modules can export functions Wasmtime can call and Wasmtime can
export functions that the module can call.
We make use of both. The terminology used is that function exports are
what the Wasm module exports and function imports are what the Wasm
runtime exports to the module.
We currently have four function imports (functions exported by the
runtime to be called by the Wasm module).
1) nxt_wasm_get_init_mem_size
This allows Wasm modules to get the size of the initially allocated
shared memory. This is the size allocated at Unit startup and what the
Wasm modules can assume they have access to (in reality this shared
memory will likely be larger).
The amount of memory allocated at startup is NXT_WASM_MEM_SIZE which as
of this commit is 32MiB.
We do actually allocate NXT_WASM_MEM_SIZE + NXT_WASM_PAGE_SIZE at
startup which is an extra 64KiB (the smallest allocation unit), this is
to allow room for the response structure and so module developers can
just assume they have the full 32MiB for their actual response.
2) nxt_wasm_send_headers
This allows WASM modules to send their headers.
3) nxt_wasm_send_response
This allows WASM modules to send their response.
4) nxt_wasm_response_end
This allows WASM modules to inform Unit they have finished sending their
response. This calls nxt_unit_request_done()
Then there are currently up to eight functions that a module can export.
Three of which are required. These function can be named anything. I'll
use the Unit configuration names to refer to them
1) request_handler
The main driving function. This may be called multiple times for a
single HTTP request if the request is larger than the shared memory.
2) malloc_handler
Used to allocate a chunk of memory at language module startup. This
memory is allocated from the WASM modules address space and is what is
sued for communicating between the WASM module (the guest) and Unit (the
host).
3) free_handler
Used to free the memory from above at language module shutdown.
Then there are the following optional handlers
1) module_init_handler
If set, called at language module startup.
2) module_end_handler
If set, called at language module shutdown.
3) request_init_handler
If set, called at the start of request. Called only once per HTTP
request.
4) request_end_handler
If set, called once all of a request has been sent to the WASM module.
5) response_end_handler
If set, called at the end of a request, once the WASM module has sent
all its headers and data.
32bits
We currently support 32bit WASM modules, I.e wasm32-wasi. Newer version
of clang, 13+[2], do seem to have support for wasm64 as a target (which
uses a LP64 model). However it's not entirely clear if the WASI SDK
fully supports[3] this and by extension WASI libc/wasi-sysroot.
64bit support is something than can be explored more thoroughly in the
future.
As such in structures that are used to communicate between the host and
guest we use 32bit ints. Even when a single byte might be enough. This
is to avoid issues with structure layout differences between a 64bit
host and 32bit guest (I.e WASM module) and the need for various bits of
structure padding depending on host architecture. Instead everything is
4-byte aligned.
[0]: <https://webassembly.org/>
[1]: <https://wasmtime.dev/>
[2]: <https://reviews.llvm.org/rG670944fb20b226fc22fa993ab521125f9adbd30a>
[3]: <https://github.com/WebAssembly/wasi-sdk/issues/185>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
| /unit/src/ |
| H A D | nxt_main_process.c | diff 2240:0c49318572c2 Tue Sep 13 14:36:00 UTC 2022 OutOfFocus4 <jeff.iadarola@gmail.com> Removed dead code.
Signed-off-by: Alejandro Colomar <alx@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 '^ [^ *+]';
diff 1872:9f8df8b810e0 Thu May 20 13:02:00 UTC 2021 Oisin Canty <o.canty@f5.com> Python: support for multiple targets.
diff 1689:e0d01647db76 Thu Nov 05 13:10:00 UTC 2020 Max Romanov <max.romanov@nginx.com> Perl: request processing in multiple threads.
This closes #486 issue on GitHub.
diff 1489:4a3ec07f4b19 Thu May 28 13:57:00 UTC 2020 Tiago Natel de Moura <t.nateldemoura@f5.com> Added "rootfs" feature.
diff 1305:966d691dab2c Fri Dec 06 13:28:00 UTC 2019 Tiago Natel <t.nateldemoura@f5.com> Moved credential-related code to nxt_credential.c.
This is required to avoid include cycles, as some nxt_clone_* functions
depend on the credential structures, but nxt_process depends on clone
structures.
diff 1254:aae6699f4eee Tue Oct 29 13:07:00 UTC 2019 Hong Zhi Dao <hongzhidao@gmail.com> Process port refactoring.
- Introduced nxt_runtime_process_port_create().
- Moved nxt_process_use() into nxt_process.c from nxt_runtime.c.
- Renamed nxt_runtime_process_remove_pid() as nxt_runtime_process_remove().
- Some public functions transformed to static.
This closes #327 issue on GitHub.
diff 1211:55773d33e999 Mon Sep 30 13:39:00 UTC 2019 Max Romanov <max.romanov@nginx.com> Fixed exiting if a signal arrives during discovery.
When Unit starts, the main process waits for module discovery message for a
while. If a QUIT signal arrives at this time, the router and controller
processes created by main and Unit stay running. Also, the main process
doesn't stop them after the second QUIT signal is received in this case.
diff 1203:fee09d50e49f Fri Sep 20 13:08:00 UTC 2019 Tiago Natel <t.nateldemoura@f5.com> Removed linux/sched.h include.
The <sched.h> is already included by nxt_unix.h.
This closes #314 PR on GitHub.
diff 1202:39a3a6a95815 Fri Sep 20 13:12:00 UTC 2019 Tiago Natel <t.nateldemoura@f5.com> Releasing init struct in case of errors.
Found by Coverity (CID 349485).
|
| H A D | nxt_conn_write.c | diff 768:d1f741314614 Tue Sep 18 13:28:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Fixed more typos.
Thanks to 洪志道 (Hong Zhi Dao).
|
| /unit/docs/ |
| H A D | changes.xml | diff 2452:751880f06069 Wed May 03 23:13:00 UTC 2023 Konstantin Pavlov <thresh@nginx.com> Packages: added Ubuntu 23.04 "lunar" support.
diff 2358:9dce85e82513 Tue Feb 28 13:42:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Added missing fixes in changes.xml.
diff 2255:05df9ea66ac2 Wed Nov 16 13:05:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: added Ubuntu 22.10 "kinetic" support.
diff 2251:6e5a9550ead3 Thu Nov 17 21:56:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Python: Added support for Python 3.11.
Python 3.8 added a new Python initialisation configuration API[0].
Python 3.11 marked the old API as deprecated resulting in the following
compiler warnings which we treat as errors, failing the build
src/python/nxt_python.c: In function ‘nxt_python_start’:
src/python/nxt_python.c:130:13: error: ‘Py_SetProgramName’ is deprecated [-Werror=deprecated-declarations]
130 | Py_SetProgramName(nxt_py_home);
| ^~~~~~~~~~~~~~~~~
In file included from /opt/python-3.11/include/python3.11/Python.h:94,
from src/python/nxt_python.c:7:
/opt/python-3.11/include/python3.11/pylifecycle.h:37:38: note: declared here
37 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetProgramName(const wchar_t *);
| ^~~~~~~~~~~~~~~~~
src/python/nxt_python.c:134:13: error: ‘Py_SetPythonHome’ is deprecated [-Werror=deprecated-declarations]
134 | Py_SetPythonHome(nxt_py_home);
| ^~~~~~~~~~~~~~~~
/opt/python-3.11/include/python3.11/pylifecycle.h:40:38: note: declared here
40 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetPythonHome(const wchar_t *);
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
We actually have a few config scenarios: Python < 3, Python >= 3.0 < 3.8
and for Python 3 we have two configs where we select one based on
virtual environment setup.
Factor out the Python 3 config initialisation into its own function. We
actually create two functions, one for Python 3.8+ and one for older
Python 3. We pick the right function to use at build time.
The new API also has error checking (where the old API doesn't) which we
handle.
[0]: https://peps.python.org/pep-0587/
Closes: <https://github.com/nginx/unit/issues/710>
[ Andrew: Expanded upon patch from @sandeep-gh ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2251:6e5a9550ead3 Thu Nov 17 21:56:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> Python: Added support for Python 3.11.
Python 3.8 added a new Python initialisation configuration API[0].
Python 3.11 marked the old API as deprecated resulting in the following
compiler warnings which we treat as errors, failing the build
src/python/nxt_python.c: In function ‘nxt_python_start’:
src/python/nxt_python.c:130:13: error: ‘Py_SetProgramName’ is deprecated [-Werror=deprecated-declarations]
130 | Py_SetProgramName(nxt_py_home);
| ^~~~~~~~~~~~~~~~~
In file included from /opt/python-3.11/include/python3.11/Python.h:94,
from src/python/nxt_python.c:7:
/opt/python-3.11/include/python3.11/pylifecycle.h:37:38: note: declared here
37 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetProgramName(const wchar_t *);
| ^~~~~~~~~~~~~~~~~
src/python/nxt_python.c:134:13: error: ‘Py_SetPythonHome’ is deprecated [-Werror=deprecated-declarations]
134 | Py_SetPythonHome(nxt_py_home);
| ^~~~~~~~~~~~~~~~
/opt/python-3.11/include/python3.11/pylifecycle.h:40:38: note: declared here
40 | Py_DEPRECATED(3.11) PyAPI_FUNC(void) Py_SetPythonHome(const wchar_t *);
| ^~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
We actually have a few config scenarios: Python < 3, Python >= 3.0 < 3.8
and for Python 3 we have two configs where we select one based on
virtual environment setup.
Factor out the Python 3 config initialisation into its own function. We
actually create two functions, one for Python 3.8+ and one for older
Python 3. We pick the right function to use at build time.
The new API also has error checking (where the old API doesn't) which we
handle.
[0]: https://peps.python.org/pep-0587/
Closes: <https://github.com/nginx/unit/issues/710>
[ Andrew: Expanded upon patch from @sandeep-gh ]
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2230:83b2d20d8f5c Fri Sep 16 13:38:00 UTC 2022 Andrew Clayton <a.clayton@nginx.com> PHP: allowed to specify URLs without a trailing '/'.
Both @lucatacconi & @mwoodpatrick reported what appears to be the same
issue on GitHub. Namely that when using the PHP language module and
trying to access a URL that is a directory but without specifying the
trailing '/', they were getting a '503 Service Unavailable' error.
Note: This is when _not_ using the 'script' option.
E.g with the following config
{
"listeners": {
"[::1]:8080": {
"pass": "applications/php"
}
},
"applications": {
"php": {
"type": "php",
"root": "/var/tmp/unit-php"
}
}
}
and with a directory path of /var/tmp/unit-php/foo containing an
index.php, you would see the following
$ curl http://localhost/foo
<title>Error 503</title>
Error 503
However
$ curl http://localhost/foo/
would work and serve up the index.php
This commit fixes the above so you get the desired behaviour without
specifying the trailing '/' by doing the following
1] If the URL doesn't end in .php and doesn't have a trailing '/'
then check if the requested path is a directory.
2) If it is a directory then create a 301 re-direct pointing to it.
This matches the behaviour of the likes of nginx, Apache and
lighttpd.
This also matches the behaviour of the "share" action in Unit.
This doesn't effect the behaviour of the 'script' option which bypasses
the nxt_php_dynamic_request() function.
This also adds a couple of tests to test/test_php_application.py to
ensure this continues to work.
Closes: <https://github.com/nginx/unit/issues/717>
Closes: <https://github.com/nginx/unit/issues/753>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
diff 2197:a9ac98dad105 Tue Sep 13 08:27:00 UTC 2022 Andrei Zeliankou <zelenkov@nginx.com> Added version 1.28.0 CHANGES.
diff 2196:7009706269f0 Tue Sep 13 08:16:00 UTC 2022 Andrei Zeliankou <zelenkov@nginx.com> Reordered changes for 1.28.0 by significance (subjective).
diff 2149:7a53238e050d Wed Jul 13 20:34:00 UTC 2022 Zhidao HONG <z.hong@f5.com> 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.
diff 2147:7bf58b1b18c4 Wed Jul 13 20:32:00 UTC 2022 Zhidao HONG <z.hong@f5.com> Var: dynamic variables support.
This commit adds the variables $arg_NAME, $header_NAME, and $cookie_NAME.
|
| /unit/ |
| H A D | version | diff 2553:f59478384175 Mon Sep 04 13:06:00 UTC 2023 Andrei Zeliankou <zelenkov@nginx.com> Version file bump.
Forgotten in f717dc15b47e.
diff 1727:1c0648dc97c1 Tue Nov 24 13:40:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Version bump.
diff 1500:29b6a0b4952f Mon Jun 08 13:09:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Version bump.
diff 1362:a15179da7e86 Wed Feb 19 16:13:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Version bump.
diff 1336:cc80a919383a Mon Jan 27 13:52:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Version bump.
diff 1291:dc702ea732ad Fri Nov 22 13:39:00 UTC 2019 Sergey Kandaurov <pluknet@nginx.com> Version bump.
953:00d8049418cf Fri Feb 22 13:31:00 UTC 2019 Alexander Borisov <alexander.borisov@nginx.com> Improvement and unification of version processing in build scripts.
This also eliminates expressions that incompatible with BSD make, thus fixing
installation of Node.js module on FreeBSD (broken by dace60fc4926).
|
| H A D | CHANGES | diff 2197:a9ac98dad105 Tue Sep 13 08:27:00 UTC 2022 Andrei Zeliankou <zelenkov@nginx.com> Added version 1.28.0 CHANGES.
diff 1891:5ae5e6619af9 Thu May 27 13:06:00 UTC 2021 Valentin Bartenev <vbart@nginx.com> Added version 1.24.0 CHANGES.
diff 1570:41371bb77803 Thu Aug 13 16:22:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Added version 1.19.0 CHANGES.
diff 1404:17772ad6d9b9 Thu Mar 12 15:13:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Added version 1.16.0 CHANGES.
diff 1222:8ffcee3c43dd Thu Oct 03 13:30:00 UTC 2019 Valentin Bartenev <vbart@nginx.com> Added version 1.12.0 CHANGES.
diff 727:75b8c59e7d95 Fri Jul 13 11:45:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Added version 1.3 CHANGES.
diff 689:5a4e29f628f8 Thu Jun 07 13:43:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Added version 1.2 CHANGES.
diff 663:8428faa304ce Thu Apr 26 13:47:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Improved wording in CHANGES.
diff 432:ab13db235c19 Thu Dec 28 13:01:00 UTC 2017 Igor Sysoev <igor@sysoev.ru> Added version 0.3 CHANGES.
|
| /unit/pkg/docker/ |
| H A D | Dockerfile.python3.11 | 2269:b91e6c4124a5 Tue Dec 13 19:50:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Regenerated Dockerfiles.
|
| H A D | Dockerfile.minimal | diff 2200:16e01c5fead4 Tue Sep 13 09:17:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Merged with the default branch.
diff 1892:847c88d10f26 Thu May 27 13:07:00 UTC 2021 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.24.0.
diff 1573:79f364e9aa90 Thu Aug 13 16:28:00 UTC 2020 Andrei Belov <defan@nginx.com> Merged with the default branch.
diff 1571:86cdf66f8274 Thu Aug 13 16:22:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.19.0.
diff 1494:1a138dda162b Thu May 28 15:13:00 UTC 2020 Andrei Belov <defan@nginx.com> Merged with the default branch.
diff 1405:8bab088952dd Thu Mar 12 15:13:00 UTC 2020 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.16.0.
diff 847:d411e7fdee9e Thu Nov 15 13:05:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.6.
diff 728:b3cf22b8a17e Fri Jul 13 11:45:00 UTC 2018 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.3.
|
| H A D | Dockerfile.jsc11 | diff 2193:15275ad20e61 Fri Sep 09 13:45:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Regenerated Dockerfiles.
diff 1892:847c88d10f26 Thu May 27 13:07:00 UTC 2021 Valentin Bartenev <vbart@nginx.com> Generated Dockerfiles for Unit 1.24.0.
|
| H A D | Dockerfile.node18 | 2269:b91e6c4124a5 Tue Dec 13 19:50:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Regenerated Dockerfiles.
|
| H A D | Dockerfile.perl5.36 | 2193:15275ad20e61 Fri Sep 09 13:45:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Regenerated Dockerfiles.
|
| H A D | Makefile | diff 2063:f05ba33bcd79 Thu Jan 13 08:35:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Docker: bumped Python image version.
diff 1786:20d0c8553094 Tue Feb 02 13:46:00 UTC 2021 Konstantin Pavlov <thresh@nginx.com> Docker: reverted 44154b830401.
Automatic synchronisation is now set up, so manual pushes to AWS ECR are
discouraged.
diff 1783:ddf5f6a322c4 Wed Jan 13 19:33:00 UTC 2021 Konstantin Pavlov <thresh@videolan.org> Docker: based docker images off official languages ones.
Language versions are bumped to:
- python 3.9
- ruby 2.7
- go 1.15
- node 15
- perl 5.32
Removed images:
- python 2.7 due to EOL
- full/latest due to incompatibility with the new scheme
diff 1764:46da19f4079f Thu Dec 24 13:17:00 UTC 2020 Andrei Belov <defan@nginx.com> Packages: fixed an ability to override package version.
This was broken since 00d8049418cf.
diff 1410:e4041da88e22 Fri Mar 13 14:35:00 UTC 2020 Konstantin Pavlov <thresh@nginx.com> Added a target to export docker images as tarballs
diff 953:00d8049418cf Fri Feb 22 13:31:00 UTC 2019 Alexander Borisov <alexander.borisov@nginx.com> Improvement and unification of version processing in build scripts.
This also eliminates expressions that incompatible with BSD make, thus fixing
installation of Node.js module on FreeBSD (broken by dace60fc4926).
|
| H A D | template.Dockerfile | 1783:ddf5f6a322c4 Wed Jan 13 19:33:00 UTC 2021 Konstantin Pavlov <thresh@videolan.org> Docker: based docker images off official languages ones.
Language versions are bumped to:
- python 3.9
- ruby 2.7
- go 1.15
- node 15
- perl 5.32
Removed images:
- python 2.7 due to EOL
- full/latest due to incompatibility with the new scheme
|
| /unit/pkg/rpm/ |
| H A D | Makefile | diff 2254:161c47a9b4f0 Wed Nov 16 13:06:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: added Fedora 37 support.
diff 2103:6e61a013417e Mon May 16 13:22:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: ship README.md and CONTRIBUTING.md.
diff 2003:28f0ed517b6e Fri Nov 12 13:45:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: added support for Fedora 35.
diff 1853:5841a506945e Wed Apr 21 13:07:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: switched to common address for package maintainers.
diff 1764:46da19f4079f Thu Dec 24 13:17:00 UTC 2020 Andrei Belov <defan@nginx.com> Packages: fixed an ability to override package version.
This was broken since 00d8049418cf.
diff 1573:79f364e9aa90 Thu Aug 13 16:28:00 UTC 2020 Andrei Belov <defan@nginx.com> Merged with the default branch.
diff 953:00d8049418cf Fri Feb 22 13:31:00 UTC 2019 Alexander Borisov <alexander.borisov@nginx.com> Improvement and unification of version processing in build scripts.
This also eliminates expressions that incompatible with BSD make, thus fixing
installation of Node.js module on FreeBSD (broken by dace60fc4926).
diff 778:e79dfec13786 Thu Sep 20 13:14:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: enabled OpenSSL support.
diff 490:db2fc04d0ee7 Mon Jan 22 13:39:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: added support for Amazon Linux.
diff 489:ee3bc6d13ad8 Mon Jan 22 13:39:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: improved per-module dependency tracking.
|
| H A D | unit.spec.in | diff 2103:6e61a013417e Mon May 16 13:22:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: ship README.md and CONTRIBUTING.md.
diff 1853:5841a506945e Wed Apr 21 13:07:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: switched to common address for package maintainers.
diff 913:bca93540f252 Thu Jan 24 13:47:00 UTC 2019 Andrei Belov <defan@nginx.com> Packages: disabled debugsource generation on relevant platforms.
In particular, this fixes unit-go package building on Fedora >= 29.
diff 778:e79dfec13786 Thu Sep 20 13:14:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: enabled OpenSSL support.
diff 490:db2fc04d0ee7 Mon Jan 22 13:39:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: added support for Amazon Linux.
|
| H A D | unit.module.spec.in | diff 1853:5841a506945e Wed Apr 21 13:07:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: switched to common address for package maintainers.
diff 913:bca93540f252 Thu Jan 24 13:47:00 UTC 2019 Andrei Belov <defan@nginx.com> Packages: disabled debugsource generation on relevant platforms.
In particular, this fixes unit-go package building on Fedora >= 29.
diff 490:db2fc04d0ee7 Mon Jan 22 13:39:00 UTC 2018 Andrei Belov <defan@nginx.com> Packages: added support for Amazon Linux.
|
| /unit/pkg/deb/debian.module/ |
| H A D | rules.in | diff 2103:6e61a013417e Mon May 16 13:22:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: ship README.md and CONTRIBUTING.md.
|
| /unit/pkg/deb/debian/ |
| H A D | rules.in | diff 2103:6e61a013417e Mon May 16 13:22:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: ship README.md and CONTRIBUTING.md.
|
| H A D | control.in | 1853:5841a506945e Wed Apr 21 13:07:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: switched to common address for package maintainers.
|
| /unit/pkg/deb/ |
| H A D | Makefile | diff 2452:751880f06069 Wed May 03 23:13:00 UTC 2023 Konstantin Pavlov <thresh@nginx.com> Packages: added Ubuntu 23.04 "lunar" support.
diff 2255:05df9ea66ac2 Wed Nov 16 13:05:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: added Ubuntu 22.10 "kinetic" support.
diff 2103:6e61a013417e Mon May 16 13:22:00 UTC 2022 Konstantin Pavlov <thresh@nginx.com> Packages: ship README.md and CONTRIBUTING.md.
diff 1941:c437a6538b69 Tue Aug 17 13:45:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: added Debian 11 "bullseye" support.
diff 1853:5841a506945e Wed Apr 21 13:07:00 UTC 2021 Andrei Belov <defan@nginx.com> Packages: switched to common address for package maintainers.
diff 1764:46da19f4079f Thu Dec 24 13:17:00 UTC 2020 Andrei Belov <defan@nginx.com> Packages: fixed an ability to override package version.
This was broken since 00d8049418cf.
diff 1694:191d30e37005 Mon Nov 09 13:12:00 UTC 2020 Andrei Belov <defan@nginx.com> Packages: added Ubuntu 20.10 "groovy" support.
diff 1494:1a138dda162b Thu May 28 15:13:00 UTC 2020 Andrei Belov <defan@nginx.com> Merged with the default branch.
diff 1290:65800375d155 Thu Nov 21 11:13:00 UTC 2019 Andrei Belov <defan@nginx.com> Packages: added Ubuntu 19.10 "eoan" support.
diff 953:00d8049418cf Fri Feb 22 13:31:00 UTC 2019 Alexander Borisov <alexander.borisov@nginx.com> Improvement and unification of version processing in build scripts.
This also eliminates expressions that incompatible with BSD make, thus fixing
installation of Node.js module on FreeBSD (broken by dace60fc4926).
|