Stream: git-wasmtime

Topic: wasmtime / issue #12943 c-api: Add wasi:http support

Wasmtime GitHub notifications bot (Apr 02 2026 at 20:11):

chaynabors opened issue #12943:

There's no C API equivalent of wasmtime_component_linker_add_wasip2 for wasi:http. Anyone using the C API or language bindings like wasmtime-py can't host components that make outbound HTTP calls through wasi:http/outgoing-handler.

wasmtime-wasi-http already has add_only_http_to_linker_sync so the changes needed on the C API side are small, following the same pattern as wasip2. I have an implementation here: https://github.com/chaynabors/wasmtime/tree/add-wasi-http-c-api

The wasi-http feature implies wasi and is disabled by default since it brings in a lot of dependencies. Our team needs this for hosting components from Python. Is there any interest in this upstream?

One open question: since wasmtime-py ships a single prebuilt dylib, there's no way to optionally include wasi-http without distributing a separate artifact. Would it make sense to include it in the default release build, or would this need to be a separate distribution?

Wasmtime GitHub notifications bot (Apr 02 2026 at 21:31):

pchickey commented on issue #12943:

I don't think we ever reasoned through exactly why wasmtime-wasi-http was left out of the c-api aloud. You're correct that it does bring in a lot of dependencies. However, it is also pretty important functionality, and generally speaking the wasmtime project wants to make your use case as easy as possible.

Maybe other maintainers can think of good reasons we shoudn't include wasmtime-wasi-http in the c-api. The c-api already depends on tokio (behind a default-enabled feature) as part of wasmtime-wasi, which is fairly heavyweight compared to the bygone pre-component non-async era, so I'm hopeful that adding hyper and the tls implementation is also acceptable.

If no objections exist, I think we should default to adding wasmtime-wasi-http to the c-api behind a feature, and enabling the feature by default. This should get it into wasmtime-py with the least amount of drama.

If for some reason we shouldnt take that path, right now the c-api doesn't appear to me to have the right sort of interfaces for applying wasmtime_wasi_http::add_only_http_to_linker_sync to a component::Linker without the c-api crate directly using the WasiHttpCtx struct and impling WasiHttpView in the manner your branch does. So, if we wanted to insist that wasmtime-wasi-http get packaged for the c-api as a separate static library, we would need to come up with interfaces in c-api that allow it.

Wasmtime GitHub notifications bot (Apr 02 2026 at 21:37):

pchickey edited a comment on issue #12943:

I don't think we ever reasoned through exactly why wasmtime-wasi-http was left out of the c-api aloud - I think its just an omission because nobody got to it. You're correct that it does bring in a lot of dependencies. However, it is also pretty important functionality, and generally speaking the wasmtime project wants to make your use case as easy as possible.

Maybe other maintainers can think of good reasons we shoudn't include wasmtime-wasi-http in the c-api. The c-api already depends on tokio (behind a default-enabled feature) as part of wasmtime-wasi, which is fairly heavyweight compared to the bygone pre-component non-async era, so I'm hopeful that adding hyper and the tls implementation is also acceptable.

If no objections exist, I think we should default to adding wasmtime-wasi-http to the c-api behind a feature, and enabling the feature by default. This should get it into wasmtime-py with the least amount of drama.

If for some reason we shouldnt take that path, right now the c-api doesn't appear to me to have the right sort of interfaces for applying wasmtime_wasi_http::add_only_http_to_linker_sync to a component::Linker without the c-api crate directly using the WasiHttpCtx struct and impling WasiHttpView in the manner your branch does. So, if we wanted to insist that wasmtime-wasi-http get packaged for the c-api as a separate static library, we would need to come up with interfaces in c-api that allow it.

Wasmtime GitHub notifications bot (Apr 02 2026 at 21:47):

pchickey commented on issue #12943:

I've completed a brief survey of the other maintainers and there are no objections at this time, so please send us a PR that adds wasmtime-wasi-http like in your branch, with feature on by default.

Wasmtime GitHub notifications bot (Apr 03 2026 at 17:06):

alexcrichton closed issue #12943:

There's no C API equivalent of wasmtime_component_linker_add_wasip2 for wasi:http. Anyone using the C API or language bindings like wasmtime-py can't host components that make outbound HTTP calls through wasi:http/outgoing-handler.

wasmtime-wasi-http already has add_only_http_to_linker_sync so the changes needed on the C API side are small, following the same pattern as wasip2. I have an implementation here: https://github.com/chaynabors/wasmtime/tree/add-wasi-http-c-api

The wasi-http feature implies wasi and is disabled by default since it brings in a lot of dependencies. Our team needs this for hosting components from Python. Is there any interest in this upstream?

One open question: since wasmtime-py ships a single prebuilt dylib, there's no way to optionally include wasi-http without distributing a separate artifact. Would it make sense to include it in the default release build, or would this need to be a separate distribution?

Last updated: Apr 13 2026 at 00:25 UTC