Feature: Support `wasi:http/proxy` world in wasmtime shim

[Mossaka]

This is a feature request for enhencing the capability of the wasmtime shim this repo provides.

Motivation

WASI HTTP proposal has reached phase 3, meaning it provides a new phase of stability. It is one of the two WASI worlds that are developed alongside with WASI preview 2. While #401 enables wasm component support in wamtime shim, it assumes the world the components are targeting to is wasi:cli/command which is POSIX main function. This proposal acts as an extension to #384 to support the wasi:http/proxy world.

wasi:http/proxy defines a collection of interfaces for sending and receiving HTTP requests and responses. The host implementation is currently supported by wasmtime v15.0.1 (e.g. via wasmtime-wasi-http crate), and wasmtime CLI provides a nice serve command handle HTTP requests from wasm files.

Feature Request

• Either extend the current wasmtime shim or create a new wasmtime-serve shim to execute wasm components targeting wasi:http/proxy world.
• Ensure full compatibility with wasm modules and the existing the worlds wasi:cli/command supported by the wasmtime shim.
• Extensive testing to validate that wasmtime serve is correct, functional and performant.

[matsbror]

I am really interested in this support. Is someone working on this? It is not as easy as to upgrade wasmtime to version 18 or higher?

[Mossaka]

Thanks! There isn't anyone working on this as far as I know, so feel free to take it on.

It is not as easy as to upgrade wasmtime to version 18 or higher?

I am afraid it's going to be more involved than just upgrading wasmtime to a higher version. As of today, the wasmtime shim only supports the wasi:cli world to be able to execute CLI programs. Supporting wasi:http/poxy means that the shim itself needs to start a HTTP server, listen to requests, and then invoke the handle function that is exported by the wasm components.

If I would implement this, I will make it very similar to how wasmtime serve command works in the wasmtime repo. (e.g. serve.rs). I would even try to make the functionalities in wasmtime serve as much reusable as possible so we don't have a large chunk of duplicated code.

Hope this helps and as usual don't hesitate to ask more questions and reach out. Happy to help!

[matsbror]

Thanks! There isn't anyone working on this as far as I know, so feel free to take it on.

I'm afraid I know too little about the inner workings of runwasi to make this in a productive manner, but I will try and we'll see how it goes.

I am afraid it's going to be more involved than just upgrading wasmtime to a higher version. As of today, the wasmtime shim only supports the wasi:cli world to be able to execute CLI programs. Supporting wasi:http/poxy means that the shim itself needs to start a HTTP server, listen to requests, and then invoke the handle function that is exported by the wasm components.

I naïvely thought that the shim could just call the cli tool wasmtime serve but I guess I need to see how the wasmtime shim is implemented now.

[Mossaka]

Yeah the shim is using wasmtime APIs to load, compile and run the wasm binaries. Supporting wasmtime serve means to use wasmtime APIs to achieve the same functionalities that wasmtime serve does.