| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When the content length is small, optimize zlib for low memory usage.
Conversely, when the content length is large, use a similar amount of
memory within zlib, as it will improve compression, and won't hurt
significantly.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
These are based on C23's <stdbit.h>.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
With this, short responses, that is, responses with a body of up to
content_length_threshold bytes, won't be compressed. The default value
is 20, as in NGINX.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
They're really more inspired in the API of BSD's strto[iu](3), but use
long just to keep it simple, instead of intmax_t, and since they wrap
strtol(3), I called them like it.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Related to:
HTTP: compress: gzip
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
|
|
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
There are still no supported encodings. This is just infrastructure for
the next commits, which will add gzip compression.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
Filter handlers are a new handler that takes place when a buffer is
about to be sent. It filters (modifies) the contents of the buffer
in-place, so that the new contents will be sent. Several filters can be
applied in a loop.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
This will allow sending the header from a totally different point, since
the data for the call is present in the request, which is available
everywhere.
It will also allow consulting in a filter if there is a body_handler
installed. The gzip filter will need this, as it should be a no-op if
there is no body handler installed.
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
nxt_min()
nxt_max()
Return the minimum/maximum of two values.
nxt_swap()
Swap the values of two variables passed by their addresses.
nxt_sizeof_array()
Return the size (in bytes) of an array.
nxt_nitems()
Return the number of elements in an array.
nxt_memberof()
Expand to a member of a structure. It uses a compound literal for
the object.
nxt_sizeof_incomplete()
Calculate the size of an incomplete type, as if sizeof() could be
applied to it.
nxt_sizeof_fam0()
Calculate the size of each element of a FAM of a structure.
nxt_sizeof_fam()
Calculate the size of a FAM of a structure.
nxt_offsetof_fam()
Calculate the offset of the nth element of the FAM from the start of
the containing structure.
nxt_sizeof_struct()
Calculate the total size of a structure containing a FAM. This
value is the one that should be used for allocating the structure.
Suggested-by: Andrew Clayton <a.clayton@nginx.com>
nxt_is_near_end()
Evaluate to true if the member is near the end of a structure. This
is only designed to be used with FAMs, to make sure that the FAM is
near the end of the structure (a zero-length array near the end of
the structure would still pass this test, but it's a reasonable
assertion to do.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
nxt_is_zero_sizeof()
Evaluate to true if the size of 'x' is 0.
nxt_is_same_type()
Evaluate to true if the both arguments are compatible types.
nxt_is_same_typeof()
Evaluate to true if the types of both arguments are compatible.
nxt_is_array()
Evaluate to true if the argument is an array.
nxt_must_be()
It's like static_assert(3), but implemented as an expression. It's
necessary for writing the must_be_array() macro. It's always
evaluates to (int) 0.
nxt_must_be_array()
Statically assert that the argument is an array. It is an
expression that always evaluates to (int) 0.
nxt_must_be_zero_sizeof()
Statically assert that the argument has a size of 0.
nxt_must_be_near_end()
Statically assert that a member of a structure is near the end of
it.
Suggested-by: David Laight <David.Laight@ACULAB.COM>
nxt_must_be_fam()
Statically assert that the argument is a flexible array member
(FAM). It's an expression that always evaluates to (int) 0.
Link: <https://gustedt.wordpress.com/2011/03/14/flexible-array-member/>
Link: <https://lore.kernel.org/lkml/202308161913.91369D4A@keescook/T/>
Link: <https://inbox.sourceware.org/gcc/dac8afb7-5026-c702-85d2-c3ad977d9a48@kernel.org/T/>
Link: <https://stackoverflow.com/a/57537491>
Link: <https://github.com/shadow-maint/shadow/pull/762>
Cc: Andrew Clayton <a.clayton@nginx.com>
Cc: Zhidao Hong <z.hong@f5.com>
Signed-off-by: Alejandro Colomar <alx@nginx.com>
|
|
|
|
|
|
|
|
|
|
Also separate header variables and "response_headers" option features.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's useful to check whether resulting images have unexpected build
leftovers.
Requires https://github.com/GoogleContainerTools/container-diff in
$PATH.
|
|
|
|
Closes #865.
|
|
|
|
|
|
|
|
|
|
It's now used to install node-gyp on nodejs images.
Starting from node:20, they no longer ship node-gyp that we require to
build the modules with, so we need to install it manually.
Fixes https://github.com/nginx/unit/issues/908.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Debian-based distributions package it automatically.
|
|
|
|
Due to the sandboxed nature of WebAssembly, by default WASM modules
don't have any access to the underlying filesystem.
There is however a capabilities based mechanism[0] for allowing such
access.
This adds a config option to the 'wasm' application type;
'access.filesystem' which takes an array of directory paths that are
then made available to the WASM module. This access works recursively,
i.e everything under a specific path is allowed access to.
Example config might look like
"access" {
"filesystem": [
"/tmp",
"/var/tmp"
]
}
The actual mechanism used allows directories to be mapped differently in
the guest. But at the moment we don't support that and just map say /tmp
to /tmp. This can be revisited if it's something users clamour for.
Network sockets are another resource that may be controlled in this
manner, for example there is a wasi_config_preopen_socket() function,
however this requires the runtime to open the network socket then
effectively pass this through to the guest.
This is something that can be revisited in the future if users desire
it.
[0]:
<https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-capabilities.md>
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This exposes various WebAssembly language module specific options.
The application type is "wasm".
There is a "module" option that is required, this specifies the full
path to the WebAssembly module to be run. This module should be in
binary format, i.e a .wasm file.
There are also currently eight function handlers that can be specified.
Three of them are _required_
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 five _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.
Example config
"applications": {
"luw-echo-request": {
"type": "wasm",
"module": "/path/to/unit-wasm/examples/c/luw-echo-request.wasm",
"request_handler": "luw_request_handler",
"malloc_handler": "luw_malloc_handler",
"free_handler": "luw_free_handler",
"module_init_handler": "luw_module_init_handler",
"module_end_handler": "luw_module_end_handler",
}
}
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This allows to configure the Wasm module, e.g
./configure wasm --include-path=/path/to/wasmtime-v11.0.0-x86_64-linux-c-api/include --lib-path=/path/to/wasmtime-v11.0.0-x86_64-linux-c-api/lib --rpath
--rpath as above says to set the rpath to the value of --lib-path. You
can alternatively specify a directory to use as the rpath. Or simply
omit the option to not have an rpath set.
This is mostly useful for during development where you may not have the
Wasmtime stuff installed to system directories or you want to test with
newer/different versions.
See ./configure wasm --help for a full list of options.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
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>
|
|
This is required to actually _build_ the Wasm language module.
The nxt_wasm_app_conf_t structure consists of the modules name, e.g
wasm, then the three required function handlers followed by the five
optional function handlers.
See the next commit for details of these function handlers.
We also need to include the u.wasm union entry that provides access to
the above structure.
The bulk of the configuration infrastructure will be added in a
subsequent commit.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This is the first patch in adding WebAssembly language module support.
This just adds a new NXT_APP_WASM type, required by subsequent commits.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
|
This makes it much more clear what's what.
This is in preparation for adding WebAssembly language module support.
Reviewed-by: Alejandro Colomar <alx@nginx.com>
Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
|
