add new HTTP header based on data from body

[sschoebinger]

Hi,

I had a use case were I wanted to add a new header (to upstream request) by parsing a value from the body of the downstream request. Unfortunately I'm not very familiar with writing wasm filters and I got the following result.

code:
I implemented on_http_request_headers and on_http_request_body of HttpContext to do

self.add_http_request_header("x-some-header", "somevalue");
Action::Continue

In on_http_request_headers that works. In on_http_request_body I get the following error:

proxy_1        | [2021-06-30 11:38:07.810][22][critical][wasm] [source/extensions/common/wasm/context.cc:1227] wasm log my_plugin my_root_id my_vm_id: panicked at 'unexpected status: 2', /usr/local/cargo/registry/src/github.aaakk.us.kg-1ecc6299db9ec823/proxy-wasm-0.1.3/src/hostcalls.rs:298:23
proxy_1        | [2021-06-30 11:38:07.810][22][error][wasm] [source/extensions/common/wasm/wasm_vm.cc:39] Function: proxy_on_request_body failed: Uncaught RuntimeError: unreachable
proxy_1        | Proxy-Wasm plugin in-VM backtrace:
proxy_1        |   0:  0xea43 - __rust_start_panic
proxy_1        |   1:  0xea37 - rust_panic
proxy_1        |   2:  0xe671 - _ZN3std9panicking20rust_panic_with_hook17h03201bc01a0ed891E
proxy_1        |   3:  0xdf25 - _ZN3std9panicking19begin_panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h29e946ca7f59bf10E
proxy_1        |   4:  0xde66 - _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h43323731dc0e6815E
proxy_1        |   5:  0xe557 - rust_begin_unwind
proxy_1        |   6:  0xddbf - _ZN3std9panicking15begin_panic_fmt17h8afdeba0f52252eeE
proxy_1        |   7:  0x246b - _ZN10proxy_wasm9hostcalls13add_map_value17h20848081c8bcb96eE
proxy_1        |   8:  0x1b33 - _ZN82_$LT$http_5xx_filter..Http5xxFilter$u20$as$u20$proxy_wasm..traits..HttpContext$GT$20on_http_request_body17h2bc5898e0bcdf8d3E
proxy_1        |   9:  0x8d2b - _ZN10proxy_wasm10dispatcher10Dispatcher20on_http_request_body17hf2277e32e545f081E

I know that this question maybe overlaps with how the envoy configuration is done (request buffering for example) but first I want to know if the proxy wasm lifecycle in general allows such a behaviour.

[rsmartins78]

I have the same problem. On my flow, I need to extract a client_id from an auth request then add it to the headers like x-auth-client-id: value, so after this, envoy can apply the rate limit based on this header.

If I add self.add_http_request_header("x-auth-client-id", client_id); inside the on_http_request_headers() it works perfectly, including the ratelimit, but then I don't have the value from the body yet. The same code inside on_http_request_body() returns

2024-11-01 14:43:02 unexpected status: 2
2024-11-01 14:43:02 [2024-11-01 13:43:02.203][32][error][wasm] [source/extensions/common/wasm/wasm_vm.cc:38] Function: proxy_on_request_body failed: Uncaught RuntimeError: unreachable
2024-11-01 14:43:02 Proxy-Wasm plugin in-VM backtrace:
2024-11-01 14:43:02   0:  0x1ff9b - __rust_start_panic
2024-11-01 14:43:02   1:  0x1feed - rust_panic
2024-11-01 14:43:02   2:  0x1fd4b - std::panicking::rust_panic_with_hook::hcbca50d2f726c5b9
2024-11-01 14:43:02   3:  0x1ee60 - std::panicking::begin_panic_handler::_$u7b$$u7b$closure$u7d$$u7d$::hd5f594164b327db3
2024-11-01 14:43:02   4:  0x1edd1 - std::sys::backtrace::__rust_end_short_backtrace::h1dcad5b9bbce3e4b
2024-11-01 14:43:02   5:  0x1f687 - rust_begin_unwind
2024-11-01 14:43:02   6:  0x24e7d - core::panicking::panic_fmt::h0e15628bec7245b3
2024-11-01 14:43:02   7:  0x19645 - proxy_wasm::hostcalls::set_map_value::h7ade7f2508a42c0f
2024-11-01 14:43:02   8:  0x568a - _$LT$envoy_client_id_extractor..HttpClientId$u20$as$u20$proxy_wasm..traits..HttpContext$GT$::on_http_request_body::h1ae3643d1514d158
2024-11-01 14:43:02   9:  0x12bd5 - proxy_wasm::dispatcher::Dispatcher::on_http_request_body::h2b7dc54a628dee6d

[mszlgr]

Looks like limitation of wasm-proxy in general that setting headers is possible only in on_http_request_headers(). I found this being mentioned as limitation in proxy-wasm-go doc.

This would mean that one is not able to replicate literally the first Lua Envoy example using wasm.