Changes in handler.rs

ab78bd82 - fix: correct various typos (#12807)

Sun, 22 Mar 2026 18:10:20 +0000

fix: correct various typos (#12807)Signed-off-by: Ho Kim List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs

365e2d89 - Refactor WASIp2 `wasi:http` implementation (#12748)

Tue, 10 Mar 2026 16:24:22 +0000

Refactor WASIp2 `wasi:http` implementation (#12748)* Sequester WASIp2 in `wasmtime-wasi-http` to a moduleThis mirrors the `wasmtime-wasi` crate's organization where there's a`p2` module and a `p3` module at the top level.* Refactor WASIp2 `wasi:http` implementationThis commit reorganizes and refactors the WASIp2 implementation of`wasi:http` to look more like other `wasmtime-wasi`-style interfaces.Specifically the old `WasiHttpImpl` structure is removed in favor ofas `WasiHttpCtxView<'_>` type that is used to implementbindgen-generated `Host` traits. This necessitated reorganizing themethods of the previous `WasiHttpView` trait like so:* The `WasiHttpView` trait is renamed to `WasiHttpHooks` to make space for a new `WasiHttpView` which behaves like `WasiView`, for example.* The `ctx` and `table` methods of `WasiHttpHooks` were removed since they'll be fields in `WasiHttpCtxView`.* Helper methods for WASIp2 were moved to methods on `WasiHttpCtxView` instead of default methods on `WasiHttpHooks`.With these changes in place the WASIp3 organization was also updatedslightly as well. Notably WASIp3 now contains a reference to the crate's`WasiHttpCtx` structure (which has field limits for example). WASIp3'sprevious `WasiHttpCtx` trait is now renamed to `WasiHttpHooks` as well.This means that there are two `WasiHttpHooks` traits right now, one forWASIp2 and one for WASIp3. In the future I would like to unify these twobut that will require some more work around the default `send_request`.A final note here is that the `WasiHttpHooks` trait previously, andcontinues to be, optional for embedders to implement. Default functionsare provided as `wasmtime_wasi_http::{p2, p3}::default_hooks`.Additionally there's a `Default for &mut dyn WasiHttpHooks`implementation, too.With all that outlined: the motivation for this change is to bring theWASIp2 and WASIp3 implementations of `wasi:http` closer together. Thisis inspired by refactorings I was doing for #12674 to apply the sameheader limitations for WASIp3 as is done for WASIp2. Prior to thischange there were a number of differences such as WASIp3 not having`crate::WasiHttpCtx` around, WASIp2 having a different organization ofstructures/borrows, etc. The goal is to bring the two implementationscloser in line with each other to make refactoring across them moreconsistent and easier.* Make `WasiHttp` in WASIp2 public* Fix some conditional build* Fix some doctests* Fix configured build* Fixup documentation List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs

1cc0bcff - feat(p3)!: vendor 0.3.0-rc-2026-01-06 (#12250)

Tue, 13 Jan 2026 22:47:24 +0000

feat(p3)!: vendor 0.3.0-rc-2026-01-06 (#12250)* feat(p3)!: vendor 0.3.0-rc-2026-01-06Update wasmtime's WASI implementation from version0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.This involves API changes in clocks and HTTP.* Handle some review comments* Update WASI implementations to avoid `as`This can have a loss in precision so this shuffles around some types toensure that `try_into` and friends are always used instead of `as`. Thischanges the source-of-truth for timestamps to be `i64` seconds so WASIp2is the odd-one-out that can't represent negative timestamps.* Flag expected WASI failures* Get wasi:http tests working again* Rename `proxy` module to `service` to reflect the WIT world.* Adjust the middleware test to using the `middleware` world.---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs

85d8cc06 - Migrate wasi-http to `wasmtime::error` (#12291)

Thu, 08 Jan 2026 20:33:01 +0000

Migrate wasi-http to `wasmtime::error` (#12291)* Migrate wiggle and wiggle generate to `wasmtime::error`* Fix testing `wiggle` and `wiggle-test` in isolationWhen doing plain old `cargo test -p wiggle` (or `wiggle-test`) the test wouldfail due to linking errors because Wasmtime's `std` cargo feature (and maybeothers) wasn't being enabled. The crate's tests would pass when run as part ofthe whole workspace, however, because of cargo feature resolution and othercrates that enabled the necessary features, which is why CI is green.* Remove direct anyhow dependency in wiggle-test* Migrate wasi-nn to `wasmtime::error`* Migrate wasi-keyvalue to `wasmtime::error`* Migrate wasi-io to `wasmtime::error`* Migrate wasi-http to `wasmtime::error` List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs

dcd65446 - support WASIp3 instance reuse in `wasmtime serve` (#11807)

Mon, 20 Oct 2025 14:55:48 +0000

support WASIp3 instance reuse in `wasmtime serve` (#11807)* support WASIp3 instance reuse in `wasmtime serve`This is a draft implementation of WASIp3 instance reuse. Previously, we usedone store and one instance per request for both p2 and p3 handlers, discardingthe store and instance immediately after the request was handled. Now weattempt to reuse p3 instances and their stores instead, both serially andconcurrently.Advantages of reuse:- Higher throughput: We can amortize the time spent creating and disposing of instances and stores over a number of requests.- Lower memory and address space usage: Concurrent instance reuse allows us to handle more requests with fewer instances, especially when the handler is I/O bound.- Developers will presumably need to make changes to their applications anyway when migrating from p2 to p3, so this is an ideal time to change the default from no reuse to (some) reuse, assuming we want to do it at all.Disadvantages of reuse:- Reduced isolation: When the same instance is used to handle multiple requests, the blast radius of bugs in the guest is larger; a trap can affect unrelated requests, and a security flaw could leak state across requests.- Host implementation complexity: There's more code to manage and more configuration knobs to tune.- Guest implementation complexity: You can't just stash state in a global variable and call it a day. Similarly, shortcuts like using a leaking GC require additional thought.Given the tradeoffs, we'll definitely need to provide components a way to optout of reuse if desired. Seehttps://github.com/WebAssembly/wasi-http/issues/190 for related discussion.Implementation details:I've moved `ProxyHandler` from `wasmtime_cli::commands::serve` to`wasmtime_wasi_http::handler` (so it can be reused by custom embedders),abstracted away the `serve`-specific parts, and added support for instance reusevia a new `ProxyHandler::push` function. The `push` function takes a work itemrepresenting an incoming request and dispatches it to a dynamically sized poolof worker tasks, each with its own store and `wasi:http/handler@0.3.x` instance.Worker tasks accept work items as capacity allows until they either reach amaximum total reuse count or hit an idle timeout, at which point they exit.Performance:I've run a few benchmarks using `wasmtime-serve-rps.sh` and[hello-wasip3-http](https://github.com/dicej/hello-wasip3-http/blob/main/src/lib.rs)(a simple "hello, world" request handler). Highlights:- 45% more requests per second with instance reuse enabled vs. disabled- 64% fewer concurrent instances required for an I/O-bound handler - Here I added a 40ms delay to the "hello, world" handler to simulate I/OTODOs:- Support host-enforced request timeouts. Note that we can't simply use the epoch-based trap-on-timeout approach we've traditionally used since a given instance may be responsible for a number of concurrent requests. This will require adding a public API to the `wasmtime` crate for cleanly cancelling a guest task without affecting other ones.- Add CLI options for the configuration knobs (e.g. max request count per instance, idle timeout, etc.)- Use guest signals like `backpressure`, explicit `wasi:cli/exit/exit`, https://github.com/WebAssembly/wasi-http/issues/190, etc. to drive reuse decisionsSigned-off-by: Joel Dice * additional instance reuse supportThis addresses a couple of TODO items from my previous instance reuse PR:- Support request timeouts by gracefully shutting down the worker as soon as any request hits a timeout, letting any other pending tasks finish or time out before actually dropping the instance.- Convert the previously hard-coded config options to CLI options.- Enable profiling when instance reuse is enabled.Signed-off-by: Joel Dice * start worker tasks more aggressivelyThis improves `wasmtime serve` performance when instance reuse is enabled by:- spawning a worker task any time there are no idle workers available- considering a worker to be unavailable until it has finished initializing itselfSigned-off-by: Joel Dice * revert unecessary wasmtime-serve-rps.sh changesSigned-off-by: Joel Dice * enable WASIp2 instance reuseSigned-off-by: Joel Dice * add clarifying comments about when and why we start worker tasksSigned-off-by: Joel Dice * remove duplicated code in `ProxyHandler::spawn`By bypassing the task queue when there are no already-available workers, I'venarrowed the performance gap between the "fast path" code and the normal path toabout 2%, which is close enough that we can remove the duplicated code.Signed-off-by: Joel Dice * ensure timeouts enforced if event loop stallsThis fixes an issue such that timeouts weren't being reliably enforced when theguest either busy loops for an extended time or makes a sync call to a hostfunction that takes exclusive access to the `Store` and blocks for a while. Ineither of those cases, the `StoreContextMut::run_concurrent` event loop willstall, being unable to make progress while the task fiber monopolizes the`Store`. In this case, we must enforce timeouts _outside_ the event loop. Seethe new code comments for details on how that is done.This also tweaks `wasmtime serve` stderr/stdout output a bit to address`cli_tests::cli_serve_*` test regressions.Signed-off-by: Joel Dice * add reuse and timeout tests to `cli_tests`This adds several new integration tests which exercise various aspects of`wasmtime serve`'s instance reuse feature, including timeouts for p2-style(synchronous) sleeps and p3-style (asynchronous) sleeps.Signed-off-by: Joel Dice * fix foreach_api breakageSigned-off-by: Joel Dice * Minor cleanups to `handler.rs`* Don't use `FutureExt`, use `async { .. }` instead.* Don't use `T`, instead use `S::StoreData`.* Shift an `unreachable!()` to be closer to the "source"* add more comments to `handler.rs`These comments draw attention to a few of the more subtle aspects of the codeand the invariants it is upholding.Signed-off-by: Joel Dice * add docs regarding the `req_id` parameterSigned-off-by: Joel Dice * add comments regarding atomic load/store orderingsThis also changes one of the `SeqCst` orderings to `Relaxed`.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasi-http/src/handler.rs