feat: add guest binding for wasi-http

[eduardomourar]

We are migrating the code from here that is implementing a basic HTTP client on top of the generated binding: https://github.com/bytecodealliance/preview2-prototyping/blob/47b30fdad11553841bbee4c5632101bbd645854b/wasi/src/http.rs

And based on the example from the wasmtime repository: https://github.com/bytecodealliance/wasmtime/blob/362696a2d363d583887a726d979944d221eb5b4b/crates/test-programs/wasi-http-tests/src/bin/outbound_request.rs

[pchickey]

Hey, sorry, this one just popped up on my feed despite it being here for a little while.

I haven't yet figured out a plan for how we are upstreaming the p2-p stuff into this crate. I suppose, for wasi-http, that since we are publishing a new crate and api, we can just go ahead and do it.

Upstreaming the functionality that currently lives in the wasi crate is a little bit trickier, since we have existing users there.

@alexcrichton do you have any objections to creating this new wasi-http crate here, with these more-idiomatic bindings on top of the wasi-http wit bindgen?

[pchickey]

http_types::Method has a FromStr method we could use to try parsing the http::Method. I don't think we should have panics in here, and instead use TryFrom.

[eduardomourar]

with the wit-bindgen v0.4, i don't have the FromStr nor the http_types::Method

[eduardomourar]

i am planning on updating those dependencies when we have the next major bump in wasmtime

[eduardomourar]

i implemented the tryfrom and returned an error instead of panicing

[pchickey]

Do we need to make a new type that Derefs to Method? Instead, we could just impl TryFrom<http::Method> for http_types::Method, and not create a new type at all.

[eduardomourar]

i am assuming that the preview2 interfaces will be imported from the crate wasi

[eduardomourar]

I finally got another PR working by using the guest binding from here, so the moment we have a new version published I can move forward.

[alexcrichton]

This all seems useful to have somewhere for sure, but I feel that this is pretty significantly diverging from what the wasi crate is doing at least. The wasi crate is effectively a "glorified *-sys crate" where it's very low-level, mostly auto-generated, and gives you effectively the raw functionality of the preview1 APIs. This new wasi-http crate, however, isn't doing that and is instead intentionally hiding the wit-bindgen-generated functionality and only exposing interop with the http crate.

Given the precedence of wasi I'd expect that the wit-bindgen-generated code would be the main public API of the wasi-http crate, with perhaps a different crate performing http interop or an optional off-by-default feature on the wasi-http crate to build in support.

There's also sort of the question of "are things ready yet" which I don't know how best to answer. This crate is relatively stable/official for preview1 but preview2 and its related support/etc aren't quite at that same level yet. I don't know how best to bridge that gap. One route is something like this where it's largley "just land it and let everyone deal with breakage later", but there's also the possibility of doing something more nuanced/measured where this is fit into a larger plan of rolling out preview2, evalutating it, etc. Or perhaps such a plan already exists and I'm not aware, unsure!

[eduardomourar]

@alexcrichton , I pushed some changes as per your suggestion by exposing the HTTP related interfaces (those would probably make more sense the wasi crate when it lands here). Also, I hid under a non-default feature flag the default HTTP client.

I believe the wasi-http will match the http crate in some sense and, later when preview2 stabilizes, we can build functionality for hyper, reqwest, surf, ureq, etc, (in their own respective repositories) when targeting wasm-wasi-preview2 on top of this crate.

[pchickey]

In DM and in bytecodealliance/preview2-prototyping#157 Eduardo and I discussed that we don't really have a great way to land preview 2 stuff in the wasi crate yet. We are going to defer figuring that out for a while by publishing the preview 2 version of the wasi crate as wasi-preview2-prototype. So, I think we are ok to close this PR for now, and revisit what to do with wasi and wasi-http in a little while.