Description
Is your feature request related to a problem? Please describe.
Proxy-wasm is an ABI spec for proxy's extensibility using WebAssembly modules, originally developed for the Wasm in Envoy project.
Proxy-wasm is an event-driven API, meaning that the Wasm module gets notified for events in which showed interest (by exporting the proper functions). Next, the module can decide whether to react to those events or not. As an example, the host will invoke proxy_on_http_request_headers into the Wasm module when headers are received from the client. Then, the Wasm module can invoke proxy_get_map on the host to retrieve the headers.
As an example, an interesting use case that could benefit from proxy-wasm support in Apache is Project Coraza, a WAF compatible with ModSecurity. There is a proxy-wasm wrapper (coraza-proxy-wasm) that could be run into mod_wasm.
Describe the solution you'd like
It could be interesting to leverage the works in #59: "Ability to extend Apache server with Wasm modules".
Similarly, we don’t need to fully implement the whole spec (that BTW is under active discussion: #38, #40, #41).
Some related project that implements part of the spec:
- The Wasm extension for Nginx (wasm-nginx-module), used in Apache APISIX.
- Kong’s proxy-wasm implementation for Nginx (aka WasmX).
- The coraza-proxy-wasm filter for Envoy.
- The Envoy proxy-wasm extension.
Given the proxy-wasm level of compliance of these projects, it seems reasonable to start providing limited proxy-wasm support in mod_wasm, initially in parity with Nginx/APISIX. Next, increase support to run Coraza WAF, and finally to be compatible with Envoy filters.
Describe alternatives you've considered
No response
Additional context
We propose four iterations to achieve this goal, that continue the works of the iterations proposed at #59:
Iteration 3: Integrate proxy-wasm-rust-sdk.
- In this iteration, we start working on implementing proxy-wasm.
- The Apache APIs exposed (from Ability to extend Apache server with Wasm modules #59) include most of the requirements needed to run all the examples in the SDK repo.
- Additionally, we will need to implement specific support for non-Apache related stuff (ie: proxy_on_tick).
- At the end of this iteration, we should be able to execute simple proxy-wasm modules.
Iteration 4: Implement proxy-wasm to support wasm-nginx (APISIX) tests.
- Upon this iteration, we should provide proxy-wasm support on parity with Nginx. So, APISIX proxy-wasm modules should be able to run in mod_wasm.
Iteration 5: Implement proxy-wasm to run coraza-proxy-wasm.
- This iteration will add additional functionality to run Coraza as a proxy-wasm filter.
Iteration 6: Implement proxy-wasm to pass envoy tests (#1, #2, #3).
- In this final iteration, mod_wasm supports all proxy-wasm tests from Envoy.