Home

Awesome

WASI HTTP

A proposed WebAssembly System Interface API.

Current Phase

wasi-http is currently in Phase 3

Champions

Portability Criteria

WASI-http must have at least two complete independent implementations demonstrating embeddability in a production HTTP server context.

Introduction

The WASI-http proposal defines a collection of interfaces for sending and receiving HTTP requests and responses. WASI-http additionally defines a world, wasi:http/proxy, that circumscribes a minimal execution environment for wasm HTTP proxies.

Goals

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/proxy 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/proxy 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/proxy world is meant to allow the chaining of HTTP intermediaries to be implemented directly in terms of Component Model linking. (Fully realizing this goal will require additional features only available in the Preview 3 timeframe.)

Non-goals

WASI-http does not intend to define a more fully-featured cloud execution environment (for this, see the wasi-cloud-core proposal).

API walk-through

The proposal can be understood by first reading the comments of proxy.wit, then handler.wit and finally types.wit.

Working with the WIT

Bindings can be generated from the wit directory via:

wit-bindgen c wit/ --world proxy

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.

References & acknowledgements