-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modify response headers values based on response body contents #62
Comments
I have a similar use case. We need to update crc-32 header after we modify response body. However, according to the docs, header modification is not allowed when we process body. |
@webngt buffering complete responses is not supported, sorry (see: proxy-wasm/proxy-wasm-cpp-host#143 (comment)). @aysee if the consumer supports it, then you should be sending updated CRC-32 value in HTTP trailers instead of headers. |
@PiotrSikora thank you for your suggestion of using HTTP trailers! I tried to use them in my sandbox project, but onResponseTrailers and onRequestTrailers are not being called. Do you have any example of how to use them?
Here is the implementation itself (just logs for debug purposes):
on*Body methods also return FilterDataStatus::Continue |
Those callbacks are called only if trailers already exist (i.e. if they were received from upstream)... and I've now realized that we don't support setting trailers if they don't already exist in Envoy, see: envoyproxy/envoy#15831. |
@aysee that PR was merged and it's included in the Envoy v1.18.0 release. There are examples for how to use it in that PR. |
@PiotrSikora thank you so much for such a quick implementation! I appreciate it! |
Is it possible to modify response header values based on response body contents? For example, if I match a certain pattern in onResponseBody I want to replace :status header value from 200 to 401 or 403 value.
According to documentation, Header API is only effective from onRequestHeader/onResponseHeader. So my task seems to be impossible to implement. Or maybe you can point to some kind of workaround?
Cheers,
Alexander.
The text was updated successfully, but these errors were encountered: