Landon James (Jun 18 2024 at 03:00): Landon James (Jun 18 2024 at 03:00):Are there any examples floating around of how to use the new (as of 21) add_to_linker_get_host functions in wasmtime-wasi-http?
I can't quite seem to figure out what to actually provide for the host_getter.
Lann Martin (Jun 18 2024 at 13:39):Most consumers are expected to use a higher level add_to_linker. If you do need more control over linking, take a look at how add_to_linker works. There is some weird indirection here because we're trying to enable different data access patterns and we've run into limitations in Rust's type system around closures and lifetimes.
Lann Martin (Jun 18 2024 at 13:41):Note that this is changing again slightly in Wasmtime 22, though again you'll just be able to look at how add_to_linker works to adapt.
Landon James (Jun 18 2024 at 13:47):It seems like the interfaces I need (types and outgoing-handler) no longer provide the basic add_to_linker and only have the _get_host version now unless I am missing something? https://docs.rs/wasmtime-wasi-http/21.0.1/wasmtime_wasi_http/?search=Add_to_linker
Lann Martin (Jun 18 2024 at 13:50):Oh I see; you aren't implementing "proxy", just outbound http
Lann Martin (Jun 18 2024 at 13:52):There actually is a variant for that but it is hidden at the moment. Maybe we could expose that.
Lann Martin (Jun 18 2024 at 13:56):https://github.com/bytecodealliance/wasmtime/issues/8832
Landon James (Jun 18 2024 at 14:04):Correcr, this is only outgoing http for a WASI compliant http client for the AWS Rust SDK. I’m just bumping our canary to use the latest wasmtime now that all the preview 2 days hints have settled. I think I can probably just add proxy to linker, although it is overkill for my needs.
Landon James (Jun 18 2024 at 14:05):Would appreciate the greater granularity for linking the http interfaces, especially if I was going to use this in a plugin sort of context where I might want to limit the interfaces provided to run untrusted code
Lann Martin (Jun 18 2024 at 14:40):You certainly can use add_to_linker_get_host, its just that we are intending/hoping it is can just be a "power user" feature so you can expect more boilerplate and less friendliness :smile:
Landon James (Jun 18 2024 at 17:09):Ahh now I'm remembering a bit more about why I split these linker bits up originally. Using both:
wasmtime_wasi::add_to_linker_async(&mut linker)?;
wasmtime_wasi_http::proxy::add_to_linker(&mut linker)?;
Results in this error:
2024-06-18T16:33:11.682943Z ERROR wasm failed:
import of `wasi:clocks/wall-clock@0.2.0` defined twice
But trying to link in only the proxy world throws:
2024-06-18T17:02:25.872804Z ERROR wasm failed:
component imports instance `wasi:cli/environment@0.2.0`, but a matching implementation was not found in the linker
Caused by:
0: instance export `get-environment` has the wrong type
1: function implementation is missing
Its been a few months, but I think the reason I was linking every interface in individually is that I kept hitting errors similar to import of 'wasi:clocks/wall-clock@0.2.0' defined twice when trying to use the higher level aggregate linker functions from both the wasmtime-wasi and wasmtime-wasi-http crates.
Last updated: Oct 23 2024 at 20:03 UTC