You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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:
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 invokeproxy_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:
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.
Iteration 4: Implement proxy-wasm to support wasm-nginx (APISIX) tests.
Iteration 5: Implement proxy-wasm to run coraza-proxy-wasm.
Iteration 6: Implement proxy-wasm to pass envoy tests (#1, #2, #3).
The text was updated successfully, but these errors were encountered: