proposals/http/README.md
A proposed WebAssembly System Interface API.
wasi-http is currently in Phase 3
WASI-http must have at least two complete independent implementations demonstrating embeddability in a production HTTP server context.
The WASI-http proposal defines a collection of interfaces for sending and
receiving HTTP requests and responses. WASI-http additionally defines two
worlds: wasi:http/service, which circumscribes an execution
environment for a broad category of HTTP services including web applications,
API servers, and proxies; and wasi:http/middleware, for services that
forward requests along a chain of handlers.
The proposal intends to abstract over HTTP version and transport protocol choices (such as HTTP/1.1, HTTP/2 or HTTP/3) by mapping directly to the abstract HTTP Semantics, allowing hosts to (mostly) transparently use any of these.
The wasi:http/service world is meant to be implementable by a wide variety of
hosts including Web service workers, forward- and reverse-proxies and
origin servers by requiring a minimal set of additional runtime support.
The wasi:http/service world is meant to support flexible auto-scaling
("serverless") execution by moving the core accept() loop into the host and
allowing the host to dynamically spin up wasm instances in response to arriving
requests.
The wasi:http/middleware world is meant to allow the chaining of HTTP
intermediaries to be implemented directly in terms of Component Model linking,
letting a request flow through a series of handlers on its way to a terminal
service while the corresponding response flows back in the opposite direction.
WASI-http does not intend to define a more fully-featured cloud execution environment (for this, see the wasi-cloud-core proposal).
The proposal can be understood by first reading the comments of worlds.wit,
then types.wit.
Bindings can be generated from the wit directory via:
wit-bindgen c wit/ --world service
and can be validated and otherwise manipulated via:
wasm-tools component wit wit/ ...
The wit/deps directory contains a live snapshot of the contents of several
other WASI proposals upon which this proposal depends. It is automatically
updated by running wit-deps update
in the root directory, which fetches the live contents of the main branch of
each proposal. As things stabilize, wit/deps.toml will be updated to refer to
versioned releases.