Wasm

This plugin requires APISIX to run on APISIX-Base, and is under construction. Currently, only a few APIs are implemented. Please follow to know the progress.

The plugin supports the following concepts from Proxy Wasm:

• All plugins run in the same Wasm VM, like the Lua plugin in the Lua VM
• Each configured route/global rules has its own PluginContext (the plugin ctx). For example, if we have a service configuring with Wasm plugin, and two routes inherit from it, there will be two plugin ctxs.
• Each HTTP request which hits the configuration will have its own HttpContext (the HTTP ctx). For example, if we configure both global rules and route, the HTTP request will have two HTTP ctxs, one for the plugin ctx from global rules and the other for the plugin ctx from route.

That’s all. Now you can use the wasm plugin as a regular plugin.

For example, enable this plugin on the specified route:

Here is the mapping between Proxy Wasm callbacks and APISIX’s phases:

• proxy_on_configure: run once there is not PluginContext for the new configuration. For example, when the first request hits the route which has Wasm plugin configured.
• proxy_on_http_request_headers: run in the access/rewrite phase, depends on the configuration of http_request_phase.
• proxy_on_http_response_headers: run in the header_filter phase.
• : run in the body_filter phase. To run this callback, we need to set property wasm_process_resp_body to non-empty value in proxy_on_http_response_headers. See t/wasm/response-rewrite/main.go as an example.

We have reimplemented some Lua plugin via Wasm, under t/wasm/ of this repo:

• fault-injection
• forward-auth