Andy Wingo (Sep 02 2025 at 07:22): Andy Wingo (Sep 02 2025 at 07:22):Consider:
extern crate wit_bindgen;
wit_bindgen::generate!({
inline: r"
package test:test;
world test {
include wasi:http/imports@0.3.0-rc-2025-08-15;
}
",
features:["clocks-timezone"],
generate_all
});
use wasi::http::types::Fields;
fn test_fields() {
let fields = Fields::new();
assert!(!fields.has(r"foo"))
}
fn main() {
test_fields()
}
Compiles fine (with nightly and --target=wasm32-wasip2). However running doesn't work:
"$HOME/src/wasip3/wasmtime/target/release/wasmtime" -Wcomponent-model-async=y -Shttp=y -Sp3=y target/wasm32-wasip2/release/http-fields.wasm
Error: failed to run main module `target/wasm32-wasip2/release/http-fields.wasm`
Caused by:
0: component imports instance `wasi:http/types@0.3.0-rc-2025-08-15`, but a matching implementation was not found in the linker
1: instance export `fields` has the wrong type
2: resource implementation is missing
This is with wasmtime compiled from git from today, built with --features component-model-async. Any ideas?
Lann Martin (Sep 02 2025 at 12:53):I don't know that the wasmtime cli has gained supprt for wasi-http p3
Lann Martin (Sep 02 2025 at 12:54):Try wasmtime serve
Andy Wingo (Sep 02 2025 at 12:55):hmm. i don't need socket support
Lann Martin (Sep 02 2025 at 12:55):ah I see hmm
Andy Wingo (Sep 02 2025 at 12:55):like, i should be able to test http without a network connection i think
Andy Wingo (Sep 02 2025 at 12:56):without listening on a port / socket i mean
Lann Martin (Sep 02 2025 at 12:58):OK well going back to my stricken comment, I don't see where wasi-http p3 is linked for the wasmtime cli
Lann Martin (Sep 02 2025 at 12:58):I could easily be missing it among the feature flag logic
Lann Martin (Sep 02 2025 at 13:02):I'd expect to see it around here: https://github.com/bytecodealliance/wasmtime/blob/10d2cbc59d35b14c3027a8542f636c591b2ec96b/src/common.rs#L389-L395
Andy Wingo (Sep 02 2025 at 13:03):hmm, i actually don't see http at all in p3/ https://github.com/bytecodealliance/wasmtime/tree/10d2cbc59d35b14c3027a8542f636c591b2ec96b/crates/wasi/src/p3
Andy Wingo (Sep 02 2025 at 13:04):so i guess http p3 needs some special linker sauce, it's in its own crate https://github.com/bytecodealliance/wasmtime/tree/main/crates/wasi-http/src
Lann Martin (Sep 02 2025 at 13:05):or here actually for run: https://github.com/bytecodealliance/wasmtime/blob/10d2cbc59d35b14c3027a8542f636c591b2ec96b/src/commands/run.rs#L976
Andy Wingo (Sep 02 2025 at 13:06):it looks like wasi-http's add_to_linker is only called from src/commands/serve.rs
Andy Wingo (Sep 02 2025 at 13:06):and not from run
Joel Dice (Sep 02 2025 at 13:06):p3 support for wasmtime-wasi-http has not yet been merged into Wasmtime -- it's all currently in https://github.com/bytecodealliance/wasip3-prototyping
Andy Wingo (Sep 02 2025 at 13:06):yaaargh :) ok :)
Andy Wingo (Sep 02 2025 at 13:07):are there decisions that need to be made before p3 http is merged to mainline ?
Andy Wingo (Sep 02 2025 at 13:08):there is a p3/ dir over at https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-http/src/p3/mod.rs, maybe it is missing things
Andy Wingo (Sep 02 2025 at 13:08):lol i see that the implementation is completely stubbed out. ok :) https://github.com/bytecodealliance/wasmtime/blob/main/crates/wasi-http/src/p3/host/types.rs
Joel Dice (Sep 02 2025 at 13:10):The main (only?) blocker right now is settling on a host-side API for futures and streams that does everything wasmtime-wasi-http needs it to, hence this discussion. I sketched an implementation out on Friday and hope to finish it today. Roman is working on updating wasmtime-wasi and wasmtime-wasi-http to use that new API. The WIP PR is github.com/bytecodealliance/wasmtime/pull/11515.
Andy Wingo (Sep 02 2025 at 13:11):hoo, that is a deep change
Andy Wingo (Sep 02 2025 at 13:15):@Joel Dice do i understand correctly that the wasmtime change is also a change to the component model async facility? or is this all hidden behind wasmtime's implementation of lowering/lifting
Joel Dice (Sep 02 2025 at 13:18):It doesn't change anything about the component model, its ABI, its semantics, or anything like that. It only affects the public API Wasmtime presents to "host embedders" (i.e. users of Wasmtime as a library) for managing streams and futures.
Andy Wingo (Sep 02 2025 at 13:20):so components still rendez-vous with each other, but the host doesn't rdv with components?
Joel Dice (Sep 02 2025 at 13:20):yeah, that's a good summary
Andy Wingo (Sep 02 2025 at 13:20):(from the perspective of the host)
Andy Wingo (Sep 02 2025 at 13:21):that makes sense to me, thanks for the explanation
Andy Wingo (Sep 02 2025 at 13:22):it sounds like i'll develop wasip3 http tests using wasip3-prototyping as the test harness for the time being, hopefully in a week or two i can run everything with upstream wasmtime then.
Andy Wingo (Sep 02 2025 at 13:27):zomg i am going crazy, i am completely holding this thing wrong:
$ ~/src/wasip3/wasip3-prototyping/target/release/wasmtime -Wcomponent-model-async=y -Sp3=y -Shttp=y target/wasm32-wasip2/release/http-fields.wasm
error: unknown -S / --wasi option: p3
$ ~/src/wasip3/wasip3-prototyping/target/release/wasmtime -Wcomponent-model-async=y -Shttp=y target/wasm32-wasip2/release/http-fields.wasm
Error: failed to run main module `target/wasm32-wasip2/release/http-fields.wasm`
Caused by:
0: component imports instance `wasi:http/types@0.3.0-rc-2025-08-15`, but a matching implementation was not found in the linker
1: instance export `fields` has the wrong type
2: resource implementation is missing
maybe we are back to what lann was saying, http not linkable from wasmtime run
Andy Wingo (Sep 02 2025 at 13:29):even though on the wasip3-prototyping branch, there is an http p3 implementation (i hope!)
Joel Dice (Sep 02 2025 at 13:29):Looks like wasip3-prototyping is using some earlier 0.3.0-draft rather than the rc: https://github.com/bytecodealliance/wasip3-prototyping/blob/main/crates/wasi-http/src/p3/wit/world.wit
Joel Dice (Sep 02 2025 at 13:31):Sorry this is such a minefield. We're racing to finish this thing while you race to test it.
Andy Wingo (Sep 02 2025 at 13:31):hey np, sympathies flow in all the directions
Andy Wingo (Sep 02 2025 at 13:32):maybe for the moment i move to testing dependencies of wasi:cli
Joel Dice (Sep 02 2025 at 13:32):Good plan
Alex Crichton (Sep 02 2025 at 14:05):The WITs for wasip3-prototyping are in spirit pretty similar to the RC but you'll want to use the literal WIT files from the repo since they're not even reflected upstream (just locally edited copies)
Alex Crichton (Sep 02 2025 at 14:06):(aka if there's other stuff to test that seems reasonable)
Roman Volosatovs (Sep 02 2025 at 14:09):FWIW, incoming HTTP is implemented in https://github.com/bytecodealliance/wasmtime/pull/11440 using latest RC
no support for wasmtime serve though and such yet
Ralph (Sep 04 2025 at 13:25):@Andy Wingo it goes without saying that we appreciate your work here......
Andy Wingo (Sep 04 2025 at 13:26):tx! am currently working on filesystem stuff; found a fun bug (?) https://github.com/bytecodealliance/wasmtime/issues/11606
Andy Wingo (Sep 04 2025 at 13:26):no idea if that's statting the real / or some fabricated dir that wasmtime uses as a root for its filesystem
Andy Wingo (Sep 04 2025 at 13:28):hmm, seems it's the real /, unless we are in a namespace
statx(3, "/", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=STATX_ATTR_MOUNT_ROOT, stx_mode=S_IFDIR|0755, stx_size=4096, ...}) = 0
fortunately the same bug is not there for openat
Andy Wingo (Sep 04 2025 at 13:40):openat2(3, "/", {flags=O_RDONLY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC, resolve=RESOLVE_NO_MAGICLINKS|RESOLVE_BENEATH}, 24) = -1 EXDEV (Invalid cross-device link)
the RESOLVE_BENEATH saves us there. but i would think that already cap-std should have filtered out a request for /, dunno.
Last updated: Dec 06 2025 at 06:05 UTC