Wasmtime exposes experimental WASIp3 support while Rust still targets wasm32-wasip2. Build a concurrent HTTP proxy with verified commands. Full breakdown.
Why Preview 3 and wasip2 Collide
Wasmtime already exposes experimental WASI Preview 3 (WASIp3) APIs, including the HTTP types you need for a real proxy, but the mainstream Rust target remains wasm32-wasip2. That split is the main source of friction. Your crate compiles against the wasip2 world and its import signatures, while the host may offer Preview 3 interfaces that look similar but are not drop-in replacements. Treat the experimental host surface as something you wire explicitly in the embedder, not something cargo build --target wasm32-wasip2 magically enables.
For an HTTP proxy, that means separating guest logic from host capabilities. Keep request parsing, routing, and response shaping in the Wasm module. Put socket creation, outbound fetch, and concurrency scheduling in the host or in thin adapters that map wasip2-shaped guest calls onto the experimental Preview 3 HTTP path. That boundary keeps the guest portable and makes the experimental pieces easy to swap when the Rust target catches up.
Shape the Guest as a Concurrent Proxy
Design the guest around a small set of operations: accept or receive an inbound request, decide an upstream target, issue an outbound request, stream or buffer the response, and return status and headers. Concurrency belongs in how you schedule those operations, not in ad hoc shared mutable state. Prefer independent request handlers that own their buffers and error paths so one slow upstream does not stall every other in-flight transfer.
- Parse method, path, and hop-by-hop headers once; strip or rewrite only what a proxy must change.
- Map each inbound request to one outbound call with an explicit timeout and cancellation path.
- Stream body chunks when possible so large payloads do not force full buffering in linear memory.
- Propagate upstream status codes and preserve safe headers; log failures without leaking sensitive values.
If your wasip2 toolchain does not yet expose the Preview 3 HTTP world directly, implement the guest against the interfaces you can link today and document the host adapter that supplies concurrency and networking. The article goal is a working proxy with a clear contract, not a single binary that pretends the target triple already matches the experimental runtime.
Wire Wasmtime and Verify Every Command
On the host side, load the module with Wasmtime, enable only the experimental WASIp3 features you need, and inject the HTTP proxy capabilities through your adapter. Keep configuration explicit: allowed upstream hosts, max concurrent requests, body size limits, and whether CONNECT or only plain HTTP methods are permitted. Fail closed when a capability is missing rather than silently falling back to incomplete behavior.
Verification should be command-level and repeatable. Build the guest for wasm32-wasip2, run the host with the experimental flags you intend to ship, then exercise the proxy with a fixed set of checks: health of the listener, a simple GET through to a known upstream, concurrent overlapping requests, a deliberate upstream error, and a cancel or timeout path. Capture exit codes and response status from each step so regressions show up as failed commands, not as vague “it felt slower” notes. When something breaks, decide whether the fault is the guest, the wasip2/Preview 3 adapter, or host limits before changing production defaults.
Practical Tradeoffs Until the Target Catches Up
Living between experimental WASIp3 in Wasmtime and a wasip2 Rust target means more glue code and stricter testing, but it also keeps you honest about capability boundaries. You get a concurrent HTTP proxy that runs today, with networking and scheduling owned by the host and business logic inside Wasm. When Rust’s default WASI target moves forward, the guest request pipeline can stay largely intact while the adapter shrinks. Until then, treat every experimental API as optional, version your host feature flags, and refuse to merge proxy changes that lack the verified command sequence above.