This PR is for issue: https://github.com/envoyproxy/envoy/issues/32090.
One of the use case is, like compression by the external processing.
This is to let the ext_proc server be able to buffer M request body
chunks from Envoy first, processing them, then send N chunks back to
Envoy in the STREAMED mode. It also let the server buffer the entire
message, i.e, header, body, trailer, before sending back any response.
The ext_proc MXN streaming works this way:
1) Enable the MXN streaming by configuring the body mode to be
FULL_DUPLEX_STREAMED in the ext_proc filter config.
2) Config the trailer mode to be SEND in the ext_proc filter config.
With above config, Envoy will send body to the ext_proc server as they
arrival. The server can buffer the entire or partial of the body (M
chunks) then streaming the mutated body(may need to split into N
chunks), back to Envoy.
---------
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72a20671ae70db520226388bfd351e817393d66e
An internal tool we have notified us that some API fields and
enum-values that we use do not have comments.
I've added some comments, and updated some of the ext-proc comments to
make it a bit clearer.
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 522c94a5e7804057433d8d5cc79aa236a564c279
## Background
We recently saw a small number of DNS queries getting timed out. There
is currently no option for us to [initialize
c-ares](https://c-ares.org/ares_init_options.html) by passing in a
custom
[timeout](https://c-ares.org/ares_init_options.html#:~:text=c%2Dares%201.5.2.-,ARES_OPT_TIMEOUTMS,-int%20timeout%3B)
and
[tries](https://c-ares.org/ares_init_options.html#:~:text=c%2Dares%201.5.2.-,ARES_OPT_TRIES,-int%20tries%3B)
config options.
## Changes
In this PR, we are adding two new options in c-ares resolver for
configuring custom timeouts and tries while resolving DNS queries.
Custom timeouts could be configured by specifying
`query_timeout_seconds` option and custom tries could be configured by
specifying `query_tries` config option.
**Commit Message:** dns resolver: add options to initialize c-ares with
custom timeout and tries
**Additional Description:** add two new options called
`query_timeout_seconds` and `query_tries` for initializing c-ares with
custom timeout and tries.
**Risk Level:** Low
**Testing:** Added Unit/Integration Tests
**Docs Changes:** Added
**Release Notes:** Added
**Platform Specific Features:** N/A
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0a2e904c7f1b8232e5e9700f2d995a76f4c84014
# Description
This change adds support for specifying an optional header to ip-tagging
filter instead of the default header that it uses (`x-envoy-ip-tags`).
example
```
http_filters
- name: ip.tagging
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.ip_tagging.v3.IPTagging
request_type: BOTH
ip_tag_header: "x-slack-foo-bar"
ip_tags: []
```
# Why
Currently, the ip-tagging filter always writes its output into the
`x-envoy-ip-tags` header. When this filter is used for more than one
purpose in the same filter chain which we do at Slack in our production
environment, we do need to take care of cleaning up the header in
between which has been proven a bit tricky sometimes. Leaking the values
in between the filter chain is bad so we try to avoid that.
We would like this to be configurable. This way we can use the optional
header instead of trying the use the same header however many times the
same filter is used on the same filter chain in a listener.
# Risk Level
this is a new feature, doesn't affect the existing functionality so
guessing low but open to changing if I'm wrong.
# Testing
added test
Docs Changes: Added, alongside release notes
Co-authored-by: Ariane van der Steldt
[avandersteldt@slack-corp.com](mailto:avandersteldt@slack-corp.com)
Signed-off-by: Radha Kumari
[rkumari@slack-corp.com](mailto:rkumari@slack-corp.com)
---------
Signed-off-by: Radha Kumari <rkumari@slack-corp.com>
Signed-off-by: Radha <kumari.radha3@gmail.com>
Signed-off-by: Radha <rkumari@slack-corp.com>
Signed-off-by: Ariane van der Steldt <avandersteldt@slack-corp.com>
Co-authored-by: Adi (Suissa) Peleg <adip@google.com>
Co-authored-by: Ariane van der Steldt <avandersteldt@slack-corp.com>
Mirrored from https://github.com/envoyproxy/envoy @ 414ad34fb35ea90e50c04d6ed85f884dd3921de7
Commit Message: kafka: close connection when rejectable request appears
Additional Description: provides
https://github.com/envoyproxy/envoy/issues/36978 by making the broker
filter check the requests' API key against allow/denylists in the config
- if we find a request to reject, we just close the connection. There is
also a bonus: this sets up a framework for "_close connection if we
don't like the request_" that we can expand upon later.
Risk Level: Low
Testing: automated (no filtering) + manual (filtering)
Docs Changes: Kafka broker .rst
Release Notes: n/a
Platform Specific Features: n/a
---------
Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c30d173544a6ac6646201f8766eb851c7c9e0bc6