Open dragoscalinescu opened 5 days ago
Yeah. Seems it's designed as that (although I don't know why). The wasm will be skipped if the request headers is not processed. In your case, the auth will send a local reply and the the request headers won't be processed by the wasm, so, the wasm will be skipped.
I think this might be due to implementation, because proxy-wasm defines a stream context that allows the wasm module to restore the context of a specific request during Envoy's asynchronous processing of multiple requests. Since this stream context is only created during the request header phase, if the wasm filter finds that the context has not been created during the response header phase, it will automatically skip.
However, this design isn't necessarily flawed; in fact, I think it might even have some advantages. While it does sacrifice some flexibility, the logic of the wasm plugin can be simpler, as it doesn’t need to account for situations where the decode phase hasn't been passed, leading to missing states.
I have an envoy configuration which contains 3 filters:
Something like this
When trying this, I only get the Lua
envoy_on_response
callback triggered, but not theon_http_response_headers
nor theon_http_response_body
wasm callbacks.Some trace logs:
Is this expected? Envoy 1.28 for context
UPDATE: External processor filters seem to behave the same way as the lua one, I am getting a
ProcessingRequest
forRESPONSE_BODY
case. Is there a different behaviour for wasm?