[WIP] Add a wasi-http support as a module

[brendandburns]

This adds basic HTTP client support as an optional module. This is intended as a draft and conversation starter.
If there are structural changes (eg. write a different proposal, a different PR, etc) please let me know, this is my first contribution.

• This has been discussed in issue Provide support for wasi-experimental-http #3483
• A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.
• Not sure who the right reviewer is, probably everyone.

Happy to close this and do this in a different way. Please advise.

Thanks!

[brendandburns]

You can see examples of this in operation here:

• Go
• C
• Typescript
• Dotnet

[pchickey]

Hi Brendan, thanks for this PR. We are excited to flesh out wasi-http and package an implementation with wasmtime. Right now the Bytecode Alliance is in the middle of a big transformation rebasing all of the Wasi interfaces on the component model, so we may need to make a couple of larger architectural changes to the approach to fit with the new way of doing things. We’ll take some time to review and figure out where those changes affect this work. We'll definitely be getting back to you, thanks!

[brendandburns]

@pchickey thanks for the response, I'm happy to commit to making the necessary changes (and even iterating along side)

I looked at WIT and the component model, but there doesn't seem to be a good example of it being actually used in wasmtime right now (wasi-nn and wasi-crypto use WITX) so whenever there is a pointer to where you want this to go please let me know.

It definitely doesn't need to be perfect, I don't mind dealing with some churn, and currently I'm having to deal with maintaining this as a patch-set, which has it's own costs :)

[brendandburns]

Similarly, if you'd prefer I simultaneously sent some PRs to the wasi-http repo, I can do that, it looked abandoned so I wasn't sure what the state was.

[pchickey]

Yep, we haven't yet landed actual use of wit in the wasmtime repository, because its not quite ready yet. I can't say for sure when it will land - its personally my top priority - but I am hoping within the next month? (I am always way too optimistic on schedule, so possibly longer.) Once we have landed basic support for the existing wasi-common functionality, then we'll port wasi-crypto and wasi-nn, and you'll have examples to follow on how to port wasi-http.

The wasi-http repo hasn't seen activity in a while because we were waiting on a bunch of this foundational wit work to be done before iterating on it again, but we're happy to have you start iterating there now!

I don't recommend adopting the witx tooling at this point, while it does work fine it is a dead end and we are focusing all of our efforts on wit.

[brendandburns]

@pchickey turns out the wasi-http repo is completely empty so I can't even fork it to send a PR.

Any chance we could get an empty README.md or somesuch, then I can start sending PRs there.

[brendandburns]

@pchickey given that the wasi-thread module was just merged, my plan is to update this PR to match how that PR worked, namely:

• Submit a WIT to https://webassembly/wasi-http
• Update this PR to match that WIT

Sound good?

[pchickey]

Thats roughly the right path, yes. threads is based on the old witx, not the new wit, so the mechanics of some wasmtime parts will work differently. I also understand that @lukewagner has an initial draft branch in that repo that he is still working on getting ready to submit as a PR, so you should take a look at that work in progress to see what you think.

We're still not able to land wit-based host implementations here but we are making progress. It probably wont land this month, though.

[brendandburns]

Closing this in favor of #5929