Companion to the behavioral issues from the wasmtime-wasi-http 47.0.3 comparison (#227, #228, #229, #230): these items are working as intended (or inherent to fetch), but guests and embedders arriving from the wasmtime ecosystem will trip on them. They belong in docs (docs/consumers.md and/or the module header at wasi/src/http.ts:40-60), not in code.
1. set-connect-timeout → not-supported is a compat trap
Spec-legal (the WIT says an error return indicates the timeout is not supported), and correctly recorded in the module header — but wasmtime accepts the call (600s default semantics), so guest code written against wasmtime that unconditionally unwraps the result traps here. Worth an explicit consumer-facing note, since it is the most likely first failure a ported guest hits.
2. Transport-level reachability differs from wasmtime by construction
fetch vs raw-TCP-plus-hyper is not just plumbing; it changes which servers are reachable and what they observe:
- HTTP version: wasmtime is HTTP/1.1 only, hardcoded (
p3/request.rs:372); fetch negotiates 1.1/2/3 per platform. h2-only endpoints work here and fail on wasmtime; header casing/connection-header behavior differs on the wire.
- Proxies: fetch honors platform proxy config (
HTTP_PROXY etc. in Deno/Node); wasmtime dials directly. Corporate-proxied environments diverge.
- Trust store: platform TLS (OS roots,
NODE_EXTRA_CA_CERTS, enterprise MITM certs) vs wasmtime's hardcoded rustls + webpki-roots with no client auth (p3/request.rs:350-356). Custom-CA deployments reach servers here that wasmtime refuses, and vice versa.
- Connection pooling: fetch pools/keep-alives; wasmtime opens a fresh TCP connection per
handle call. Server-side connection accounting and keep-alive behavior differ.
None of this is fixable without abandoning fetch, which is the fragment's whole premise; the ask is a short "reachability and transport differences vs wasmtime" section so embedders can predict it.
Companion to the behavioral issues from the wasmtime-wasi-http 47.0.3 comparison (#227, #228, #229, #230): these items are working as intended (or inherent to fetch), but guests and embedders arriving from the wasmtime ecosystem will trip on them. They belong in docs (docs/consumers.md and/or the module header at wasi/src/http.ts:40-60), not in code.
1.
set-connect-timeout→not-supportedis a compat trapSpec-legal (the WIT says an error return indicates the timeout is not supported), and correctly recorded in the module header — but wasmtime accepts the call (600s default semantics), so guest code written against wasmtime that unconditionally unwraps the result traps here. Worth an explicit consumer-facing note, since it is the most likely first failure a ported guest hits.
2. Transport-level reachability differs from wasmtime by construction
fetch vs raw-TCP-plus-hyper is not just plumbing; it changes which servers are reachable and what they observe:
p3/request.rs:372); fetch negotiates 1.1/2/3 per platform. h2-only endpoints work here and fail on wasmtime; header casing/connection-header behavior differs on the wire.HTTP_PROXYetc. in Deno/Node); wasmtime dials directly. Corporate-proxied environments diverge.NODE_EXTRA_CA_CERTS, enterprise MITM certs) vs wasmtime's hardcoded rustls + webpki-roots with no client auth (p3/request.rs:350-356). Custom-CA deployments reach servers here that wasmtime refuses, and vice versa.handlecall. Server-side connection accounting and keep-alive behavior differ.None of this is fixable without abandoning fetch, which is the fragment's whole premise; the ask is a short "reachability and transport differences vs wasmtime" section so embedders can predict it.