spec
spec copied to clipboard
proxy-wasm
WebAssembly for Proxies (ABI specification)
Since gRPC it's built on top of HTTP, it's debatable whether we need a specialized hostcall for gRPC callouts or if SDKs could provide them themselves. As far as I...
Existing interface requires passing complete HTTP request body or gRPC message in HTTP/gRPC callouts. We should be able to stream those, enabling request mirroring, etc.
Once we start passing resource IDs in hostcalls (#59), we should be able to use existing [`proxy_on_response_headers`](https://github.com/proxy-wasm/spec/tree/main/abi-versions/v0.2.1#proxy_on_response_headers), [`proxy_on_response_body`](https://github.com/proxy-wasm/spec/tree/main/abi-versions/v0.2.1#proxy_on_response_body), and [`proxy_on_response_trailers`](https://github.com/proxy-wasm/spec/tree/main/abi-versions/v0.2.1#proxy_on_response_trailers) instead of [`proxy_on_http_call_response`](https://github.com/proxy-wasm/spec/tree/main/abi-versions/v0.2.1#proxy_on_http_call_response).
We should be able to ask host to flush partial data instead of buffering it.
We should have a way to control the `end_of_stream` flag, since right now we cannot do some modifications (e.g. forward HTTP headers with added `end_of_stream` flag, but strip HTTP request...
As a developer who wants to create filters using Proxy-WASM it is hard to understand the exact lifecycle of filters. It doesn't seem to be documented anywhere. It would be...
Right now, the upstream name used inside plugin must match configured upstream name in the host, but we don't provide any recommendations around its format, which makes this feature less...
Currently, we're passing strings across the ABI boundary to represent static values. Most notable examples are properties and custom function names for hostcalls and callbacks. We should move away from...
Currently, the effective `context_id` is tracked by the host, but this results in a weird asymmetry between hostcalls (without `context_id`) and callbacks (with `context_id`), and makes it harder to build...
Currently, some resources are global and always open. With this change, we could e.g. introduce the ability to create and delete new KV stores, so that unrelated keys don't have...