summaryrefslogtreecommitdiffhomepage
path: root/src/wasm-wasi-component (follow)
AgeCommit message (Collapse)AuthorFilesLines
2024-09-04wasm-wc: Enable environment inheritanceRobbie McKinstry1-0/+1
While the C based wasm language module inherits the process environment the Rust based wasm-wasi-component language module did not. One upshot of this is that with wasm-wasi-component you don't get access to any environment variables specified in the Unit configuration. wasm-wasi-component was based on wasmtime 17.0.0. This capability wasn't added to the wasmtime-crate until version 20.0.0. Now that wasm-wasi-component has been updated to a newer wasmtime-crate we can enable this functionality. Closes: https://github.com/nginx/unit/issues/1312 [ Commit message - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-09-04wasm-wc: bump wasmtime to v24Ava Hahn3-299/+334
Signed-off-by: Ava Hahn <a.hahn@f5.com>
2024-04-19wasm-wc: Bump the rustls crate from 0.21.10 to 0.21.11dependabot[bot]1-2/+2
Bumps <https://github.com/rustls/rustls> from 0.21.10 to 0.21.11. "This release corrects a denial-of-service condition in rustls::ConnectionCommon::complete_io(), reachable via network input. If a close_notify alert is received during a handshake, complete_io() did not terminate. Callers which do not call complete_io() are not affected." The wasm-wasi-component language module is not effected by this as it doesn't handle client connections, Unit does. Link: Release notes <https://github.com/rustls/rustls/releases> Link: Commits <https://github.com/rustls/rustls/compare/v/0.21.10...v/0.21.11> Signed-off-by: dependabot[bot] <support@github.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-04-09Wasm-wc: Bump the h2 crate from 0.4.2 to 0.4.4dependabot[bot]1-2/+2
Bumps h2 <https://github.com/hyperium/h2> from 0.4.2 to 0.4.4. Limit number of CONTINUATION frames for misbehaving connections. Link: Changelog <https://github.com/hyperium/h2/blob/master/CHANGELOG.md> Link: Commits <https://github.com/hyperium/h2/compare/v0.4.2...v0.4.4> Signed-off-by: dependabot[bot] <support@github.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-14Wasm-wc: Fix application restartsAndrew Clayton1-3/+12
Liam reported a problem when trying to restart wasm-wasi-component based applications using the /control/applications/APPLICATION_NAME/restart endpoint. The application would become unresponsive. What was happening was the old application process(es) weren't exit(3)ing and so while we were starting new application processes, the old ones were still hanging around in a non-functioning state. When we are terminating an application it must call exit(3). So that's what we do. We use the return value of nxt_unit_run() as the exit status. Due to exit(3)ing we also need to now explicitly handle the return on error case. Reported-by: Liam Crilly <liam@nginx.com> Fixes: 20ada4b5c ("Wasm-wc: Core of initial Wasm component model language module support") Closes: https://github.com/nginx/unit/issues/1179 Tested-by: Liam Crilly <liam@nginx.com> Tested-by: Danielle De Leo <d.deleo@f5.com> Co-developed-by: Dan Callahan <d.callahan@f5.com> Signed-off-by: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-03-11Wasm-wc: Bump the mio crate from 0.8.10 to 0.8.11dependabot[bot]1-2/+2
Bumps mio <https://github.com/tokio-rs/mio> from 0.8.10 to 0.8.11. Fixes receiving IOCP events after deregistering a Windows named pipe. Not that that effects Unit... Link: <https://github.com/nginx/unit/security/dependabot/1> Link: Changelog <https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md> Link: Commits <https://github.com/tokio-rs/mio/compare/v0.8.10...v0.8.11> Signed-off-by: dependabot[bot] <support@github.com> Reviewed-by: Andrew Clayton <a.clayton@nginx.com> [ Tweaked commit message/subject - Andrew ] Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Add Cargo.lockAndrew Clayton2-2/+2293
It seems we do want to track this thing. This is just the latest version that cargo had generated for me. Cc: Dan Callahan <d.callahan@f5.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Allow to use the 'reactor' adaptor againAndrew Clayton1-1/+2
With the initial port to wasmtime 17 we could no longer use the 'reactor' adaptor but had to switch to the more restrictive 'proxy' adaptor. This meant amongst other things (probably) we could no longer access the filesystem. Thanks to Joel Dice for pointing out the fix. With this we can go back to using the 'reactor' adaptor again and things are back to working as before. It's worth noting that you can use either the 'proxy' or 'reactor' adaptor depending on your requirements. Cc: Joel Dice <joel.dice@fermyon.com> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Upgrade to wasmtime 17Andrew Clayton2-16/+17
This brings WASI 0.2.0 support. Link: <https://github.com/bytecodealliance/wasmtime/releases/tag/v17.0.0> Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Improve request buffer handlingAndrew Clayton1-7/+14
When Unit receives a request, if the body of that request is greater than a certain amount (16KiB by default) then it is written to a temporary file. When a language module goes to read the request body in such situations it will end up using read(2). The wasm-wasi-component language module was failing to properly read request bodies of around 2GiB or more. This is because (on Linux at least) read(2) (and other related system calls) will only read (or write) at most 0x7ffff000 (2,147,479,552) bytes, this is the case for both 32 and 64-bit systems. Regardless, it's probably not a good idea doing IO in such large chunks anyway. This patch changes the wasm-wasi-component language module to read the request buffer in 32MiB chunks (this matches the original 'wasm' language module). We are still limited to a 4GiB address space and can only upload files a little under 4GiB. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Run src/lib.rs through rustfmtAndrew Clayton1-31/+84
Run from the repository root like $ rustfmt --edition 2021 src/wasm-wasi-component/src/lib.rs Also manually fix up some overly long comments. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>
2024-02-21Wasm-wc: Core of initial Wasm component model language module supportAlex Crichton5-0/+620
This is the work of Alex Crichton. This is written in Rust. The problem is that there is currently no support on the C side of things for the component model, which is the point of this module. It talks to Unit via automatically generated bindings. I've (Andrew) just made some minor tweaks to src/lib.rs, build.rs & Cargo.toml to adjust some paths, adjust where we get the language module config from and the module name and where it's located in the source tree, I also removed and disabled the tracking of the Cargo.lock file, this is constantly changing and not tracking it seems right for 'libraries' and dropped the README's... Other than that I have tried to leave his work intact, subsequent commits will make some larger changes, but I didn't want to intermix them with Alex's work. One such commit will update the module to use wasmtime 17 which brings WASI 0.2.0 support. Signed-off-by: Andrew Clayton <a.clayton@nginx.com>