Clarify proxy_action_t values

[banks]

The current draft spec does't anywhere define what values proxy_action_t might take.

The C++ and Rust SDKs also seem to diverge on this, the Rust SDK only provides Action::Continue and Action::Pause for all handlers. The CPP SDK seems to define differnt actions for HTTP headers which include being able to terminate the stream.

It's not clear what is expected here!

For context, I'm attempting to write a WASM filter for Envoy currently.

I'm writing an L4 (Stream Context) filter that needs to determine if the caller is authorized to access the service. If not I need to be able to terminate the connection.

As far as I can see there is no way to do this currently - the Rust SDK only defines Continue and Pause which will just hang the connection not terminate it.

I also tried calling self.done() on the StreamContext to attempt to terminate that TCP stream however that causes Envoy to segfault so I presume that is not the correct way to achieve that. I don't see any other method in the ABI spec that would allow terminating the current stream though - is this intended to work?

Thanks for your help. I'm looking forward to proxy-wasm stablizing!

[banks]

Extra info: since my authorizer is looking at the client TLS principal, it has to happen in proxy_on_downstream_data handler now since the proxy_on_new_connection one fires when the TCP connection is made before the TLS handshake (which makes sense as you may want to intercept the handshake too). Both of these handlers are limited to only returning Continue or Pause/StopIterarion currently though so it would seem there is no option to RST the connection from a filter currently?

[esnible]

I am also trying to understand how to read this. I see proxy_on_http_request_body returns i32 (proxy_action_t) next_action.

I suspect the actions are the enumerations defined in https://github.com/envoyproxy/envoy/blob/master/include/envoy/http/filter.h . Including the enumerations in the spec would help.

I suspect functions must abide by the same contract as Envoy extensions, e.g. the rules mentioned in https://www.envoyproxy.io/docs/envoy/latest/faq/extensions/contract.html#is-there-a-contract-my-http-filter-must-adhere-to . This is also not spelled out.

I have looked at native Envoy filter source code but never written one. The spec should incorporate, by value or by reference, sufficient information on enumerations and on state management.

[mathetake]

I believe this will be resolved by our project overhaul. Please refer to #39 (comment) for the context. Thanks!