bytecodealliance
wasi:http type conversions
Is there a recommended method to convert the WASI-http proxy world's types to those used in the greater Rust ecosystem, in the http crate?
Would it be suitable for such a conversion to be hosted under the wasi crate? (Likely under a feature flag?)
The wasmtime-wasi-http crate may also be of relevance here, although I haven't dug too deeply just yet.
This is the rough intention of the wasi-ext crate but that is not fully fleshed out at this time. Being an external crate it has to be manual methods as well instead of trait implementations since both types being referred to are in external crates.
Overall the answer at this time is generally: "Unsure". These would make sense to eventually live within the wasi crate itself but it's not clear whether that's a good fit at this time given the core and low-level nature of the wasi crate.
wasmtime-wasi-http is wasmtime's host implementation of wasi-http, whereas this crate (wasi-rs) is for exposing wasi-http (and other wasi proposals) to guests, so that work won't be relevant here.
I'd be fine reviewing additions to this for conversions to/from the http crate representations, where the dep on http is behind an off-by-default feature.
You may also want to look at wstd where we have built more useful Rust abstractions on top of the bindings than just conversion functions can provide. There, we are using http's types as part of wstd's public interface as much as possible.
I'd be fine reviewing additions to this for conversions to/from the
httpcrate representations, where the dep onhttpis behind an off-by-default feature.
Yep, exactly my thoughts as well
for exposing wasi-http (and other wasi proposals) to guests, so that work won't be relevant here.
My current usecase is actually plugging in the IncomingRequest type to external ecosystem crates (e.g constructing an axum router and dispatching it on a single request).
From what it seems, wasmtime-wasi-http does a lot of validation in the conversions. I'm not sure the security posture of this crate, but would/should these validations be elided from the implementation, assuming that the host has created a proper hyper HTTP request? I'll likely tinker with this on the side and upstream / draft a PR if something gets workable.
My current usecase is actually plugging in the IncomingRequest type to external ecosystem crates (e.g constructing an axum router and dispatching it on a single request).
Because you are in the wasi-rs crate's issue tracker, I want to clarify that this means a mapping that is used for guest code, i.e. code which is compiled with --target wasm32-wasip2, which produces a Wasm Component. Those components are run in a wasm engine (wasmtime or jco or embeddings built out of those like fermyon's spin or cosmonic's wasm-cloud, or etc...) and the wasm engine provides host implementations of all of the functions imported by those components.
It would be very valuable to the community to make it possible to run external ecosystem crates, like axum, inside a component. The best possible outcome, from my perspective, is that a crate such as axum has a dependency on the wasi crate guarded by #[cfg(target_family="wasm", target_env = "p2")] and uses those bindings directly in its implementation, rather than raw sockets and HTTP protocol serializer/deserializer and a tls implementation such as rustls. However, since thats a pretty big architectural departure from what axum and its peers have today, we created wstd as an intermediate solution that folks can use today, and to demonstrate to axum and its peers's maintainers how a wasi-http component works.
wstd isn't very fleshed out in terms of usability, its very much a prototype in the direction of something nicer than the raw bindings. So, one thing you could do that is much less ambitious than porting all of axum to wasmtime-wasip2 is making a derivative of axum (e.g. axum_wstd) which uses wstd under the hood, which users could port many existing axum programs to by using it as axum_wstd = { version = "...", package = "axum" } in a Cargo.toml.
wasmtime-wasi-http is a host implementation of wasi-http, which means it operates at the same trust level as the wasmtime engine itself. All that wasmtime guarantees to wasmtime-wasi-http is that the arguments passed to import functions conform to the type system described in the wasi-http wit, but further validation is required in some cases to map that to hyper, or else return an appropriate error code to the wasi-http guest. Its use of hyper under the hood is incidental, and in general any component you create using the wasi-http imports or proxy world should run on any engine supporting those worlds, which could be built on totally different http implementations under the hood.