use case that is not working - http_dispatch_call in on_http_response_body and on_http_call_response_body want to update response body

[joseret]

Logic is working and using shared data to store intermediate results from http_dispatch_call to on_http_call_response_body, but when I try to replace the response_body. No method is working, generates a panic.

tried combinations of these

             // self.set_http_response_body(0, json_bytes.len(), v);
              // self.send_http_response(201, vec![], Some(json_bytes_au8));
              // wasm::types::Action::Continue;
              self.resume_http_response();

It there something I am missing. probably best is if you can help on the right calls to update the response body and then finish during the fn on_http_call_response(&mut self,

[joseret]

ping. Anyone have some thoughts on this?

[zendesk-fcamenfo]

The flow that works for me is something like this:

• on_http_request_body() -> perform http_dispatch_call, return Action::Pause
• on_http_call_response() -> receive result from HTTP call, modify body with set_http_response_body() and then call resume_http_resposne()

[joseret]

Thanks! Yes, that works for me too. But I need the initial on_http_response_body to retrieve some information used on the dispatch call and that is where I am stuck and it would seem that proxy is in a state that cannot change the body, since I got to on_http_response_body complete data

[zendesk-fcamenfo]

Not sure I understand what the problem is. This flow works on my end:

• Retrieve data from the body when in on_http_request_body, then use it on an HTTP dispatch call.
  • Return Action::Pause so the body is still buffered and can be changed
• Modify the body when in on_http_call_response, which would happen after on_http_request_body has completed. Then resume sending upstream with resume_http_response()

Are you getting some error?

[joseret]

I am issuing thee HTTP dispatch in the on_http_response_body (not in the on_http_request_body so how do I receive the response_body, then do dispatch, and from on_response_call_body modify the response_body going to requestor. Hopefully tha tshows thee difference. Two difference sequences in two different states. I will attach the envoy trace and see if that helps clarify but seems to be we can't buffeer on_http_response and then change it (or can we?)

[zendesk-fcamenfo]

Just tried and it works with my codebase (uses GRPC instead of HTTP but should work the same). Version 0.1.4 of proxy-wasm.

1. on_http_response_body() -> wait until _end_of_stream = true, then perform dispatch_grpc_call(), then return Action::Pause
2. on_grpc_call_response() -> perform set_http_response_body(), then call resume_http_response()

And I can see the modified body being returned to a curl command.

One other thing, have you removed the content-length header before modifying the body?

[joseret]

Great news, let me try that. I thought I removed the content-length but will make sure and post logs

On Wed, Jun 22, 2022 at 7:28 AM Francisco Camenforte Torres < @.***> wrote:

Just tried and it works with my codebase (uses GRPC instead of HTTP but should work the same). Version 0.1.4 of proxy-wasm.

1. on_http_response_body() -> wait until _end_of_stream = true, then perform dispatch_grpc_call(), then return Action::Pause
2. on_grpc_call_response() -> perform set_http_response_body(), then call resume_http_response()

And I can see the modified body being returned to a curl command.

One other thing, have you removed the content-length header before modifying the body?

— Reply to this email directly, view it on GitHub https://github.com/proxy-wasm/proxy-wasm-rust-sdk/issues/156#issuecomment-1163175617, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGMVR5TIHCMPV7I3TIJB6ADVQMPJ5ANCNFSM5YMANL2A . You are receiving this because you authored the thread.Message ID: @.***>

-- Jose Retelny Google Cloud PSO - Application Engineer @.*** phone:650-499-1516

[joseret]

Great to hear. I thought I remove content header on the response_header but will make suree

[zendesk-fcamenfo]

Also make sure you are setting the start and size parameters correctly in set_http_response_body

If I remember correctly, a (size < new body size) will perform a prepend operation on the body

[joseret]

This is similar error, there is no content-length header, so set_request_headers fail

[2022-06-22 22:52:17.219][516433][critical][wasm] [external/envoy/source/extensions/common/wasm/context.cc:1227] wasm log my_plugin my_root_id my_vm_id: panicked at 'unexpected status: 2', /home/jr/.cargo/registry/src/github.com-1ecc6299db9ec823/proxy-wasm-0.1.4/src/hostcalls.rs:211:23 [2022-06-22 22:52:17.219][516433][error][wasm] [external/envoy/source/extensions/common/wasm/wasm_vm.cc:39] Function: proxy_on_http_call_response failed: Uncaught RuntimeError: unreachable Proxy-Wasm plugin in-VM backtrace: 0: 0x32809 - __rust_start_panic 1: 0x3231e - rust_panic 2: 0x322ee - _ZN3std9panicking20rust_panic_with_hook17h623ac32ff431b114E 3: 0x31926 - ZN3std9panicking19begin_panic_handler28$u7b$$u7b$closure$u7d$$u7d$17h4939ceabc7a11060E 4: 0x31865 - _ZN3std10sys_common9backtrace26__rust_end_short_backtrace17h9f6add6df687a1bfE 5: 0x31f60 - rust_begin_unwind 6: 0x3948d - _ZN4core9panicking9panic_fmt17h5118e89563022e7eE 7: 0x213be - _ZN10proxy_wasm9hostcalls7set_map17h8814604a6362fcdfE 8: 0x477f - ZN96$LT$rust_filter_poc_v1..FilterApplicationHttpHandler$u20$as$u20$proxy_wasm..traits..Context$GT$21on_http_call_response17h27af8f70079c8cd4E 9: 0x1d235 - _ZN10proxy_wasm10dispatcher10Dispatcher21on_http_call_response17h12866b54eb9eea98E

[joseret]

error.log Here is the trace

[zendesk-fcamenfo]

Yes, that's a different case than the body. When you're at or past the on_http_request/response_body callbacks, the HTTP headers have already been forwarded up or downstream. It's not allowed to buffer the headers along with the body. So no header modification is possible at that stage.

I've been hit by the same problem, you can only modify headers when in the on_http_request/response_headers callback.

I think this is related: https://github.com/proxy-wasm/proxy-wasm-cpp-host/issues/143