Commit Message: ignore request_header_mode in mode override comparison,
it's not applicable in anyway, but it does interfere mode matching if
allowed_override_modes is configured.
Additional Description: This is a sister PR of #38254, let's simply
ignore the request_header_mode in mode comparison as it's not
applicable. OTOH, it does introduce confusion in allowed_override_modes
comparison.
Risk Level: LOW.
Testing: unit test
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: Xin Zhuang <stevenzzz@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 504f5b01d0f123013fd6cb202382f1e3aa4cf2e7
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
Commit Message: LocalRateLimit(HTTP): Add dynamic token bucket support
Additional Description:
fixes: https://github.com/envoyproxy/envoy/issues/23351 and
https://github.com/envoyproxy/envoy/issues/19895
User configures
[descriptors](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/common/ratelimit/v3/ratelimit.proto#envoy-v3-api-msg-extensions-common-ratelimit-v3-localratelimitdescriptor)
in the [http local rate limit
filter](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/local_ratelimit/v3/local_rate_limit.proto).
These descriptors are the "target" to match using the source descriptors
built using the traffic(http requests). Only matched traffic will be
rate limited. When request comes, at runtime, based on
[rate_limit](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-ratelimit)
configuration, descriptors are generated where `values` are picked from
the request as directed by the rate_limit configuration. These generated
descriptors are matched with "target"(user configured) descriptors.
Generated descriptors are very flexible already in the sense that
"values" from the request can be extracted using number of ways such as
dynamic metadata, matcher api, computed reg expressions etc etc, but in
"target"(user configured) descriptors are very rigid and it is expected
that user statically configures the "values" in the descriptor.
This PR is adding flexibility by allowing blank "values" in the user
configured descriptors. Blank values will be treated as wildcard.
Suppose descriptor entry key is `client-id` and value is left blank by
the user, local rate limit filter will create a descriptor dynamically
for each unique value of header `client-id`. That means `client1`,
`client2` and so on will have dedicated descriptors and token buckets.
To keep a resource consumption under limit, LRU cache is maintained for
dynamic descriptors with a default size of 20, which is configurable.
Docs Changes: TODO
Release Notes: TODO
---------
Signed-off-by: Vikas Choudhary (vikasc) <choudharyvikas16@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c32e210ca1e2668eb5cf2b2bacc36acbc7f4d4b9
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
Commit Message:
This commit introduces support for injecting custom TLVs into the Proxy
Protocol v2 (PP2) header for upstream transport sockets. This enables
xDS control planes to build upstream PP2 headers with greater
flexibility. Previously, upstream PP2 headers only passed through TLVs
from downstream connections when using the Proxy Protocol listener,
limiting customization.
With this change, users can define custom TLVs by configuring the
`custom_tlvs` field in the upstream_proxy_protocol transport socket
config, or specifying host metadata in a well-known namespace in order
to provide dynamic and more granular control over PP2 header content.
For example:
```yaml
transport_socket:
name: envoy.transport_sockets.upstream_proxy_protocol
typed_config:
"@type": type.googleapis.com/envoy.extensions.transport_sockets.proxy_protocol.v3.ProxyProtocolUpstreamTransport
config:
version: V2
added_tlvs:
- type: 150
value: Zm9v
- type: 151
value: YmFy
```
And
```yaml
clusters:
- name: httpbin
load_assignment:
...
endpoints:
- lbEndpoints:
- metadata:
filter_metadata:
envoy.transport_socket_match:
outbound-proxy: true
typed_filter_metadata:
envoy.transport_sockets.proxy_protocol:
"@type": type.googleapis.com/envoy.config.core.v3.ProxyProtocolConfig
added_tlvs:
- type: 0xD7
value: b3Zy
- type: 0xD8
value: bmV3
...
```
By decoupling upstream PP2 customization from downstream listener
config, this unlocks more flexible use cases for Proxy Protocol in
upstream paths.
Additional Description: N/A
Risk Level: Low
Testing: Unit & integration
Docs Changes: Include in the protobuf docs
Release Notes: Included in the changelog as a new feature
Platform Specific Features: N/A
[Optional Runtime guard:]
[Optional Fixes #Issue] https://github.com/envoyproxy/envoy/issues/18520
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: timflannagan <timflannagan@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 90e99327ff399e21d9320d73c47bee5bec577ebc
The mode_override feature has a very surprising behavior, in which unset
fields in ProcessingMode, revert behavior back to the default. For
example, it is the default behavior that resposne headers are sent, but
if the filter is configured not to send response headers in
processing_mode, and a mode_override is sent to explicitly send request
body, this then inadvertently triggers the sending of response headers
as well, as the mode has been overriden back to the "default". We have
seen ext_proc users of mode_override being affected by these confusing
semantics.
It seems far more sensible that a mode_override only affects the
processing mode features explicitly set in the mode_override message.
Technically this could be a breaking wire change, but it seems unlikely
that anyone is relying on the default override, as they would most
likely just set response headers to SEND instead of DEFAULT if that was
the intended behavior.
This is a protocol change proposal, which will be augmented with
implementation if there is agreement on this approach.
Risk level: Medium
Testing: Unit test
Docs Changes: API docs updated.
Release Notes: Clarification added.
---------
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 725a25b95b516577432e1b3d3401f773e976bbe0
JWT stands for *JSON Web Token*. Code comments and documentation both
contain many "JWT token" which is double.
This pull request replaces those pieces of text with JWT (or sometimes
plural).
This pull request should have no code changes.
Signed-off-by: hidde.wieringa <hidde.wieringa@nedap.com>
Mirrored from https://github.com/envoyproxy/envoy @ e9ee7fa41ae423d2b4fd7f8db758fc62884e619e
Commit Message: Enable dynamic modules & Add high level doc
Additional Description:
This adds a high level documentation of dynamic_modules feature
that has been developed over the last few months and has finally
become usable for users.
closes#2053closes#24230closes#32502
Risk Level: low
Testing: existing ones
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
---------
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Co-authored-by: phlax <phlax@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ fe58ab14eaffbaab96b66300af0afce14aa4d95a
Commit Message: Adds a feature to disable DNS refresh on failure by
setting `DnsCache.disable_dns_refresh_on_failure` to true. By enabling
this feature, failed hosts will be treated as a cache miss.
Additional Description: In a mobile environment where the network
connectivity can change a lot, such as airplane mode, offline to online,
switching from cellular to WiFi, etc., using the DNS cache for the
failed hosts means the requests to those hosts will automatically fail
until the next DNS cache refresh. Having an automatic DNS refresh on
failures unnecessarily (such as when the device is offline) can also
waste the battery life.
Risk Level: low (a new feature)
Testing: unit and integration tests
Docs Changes: inline
Release Notes: inline
Platform Specific Features: dfp
---------
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c0a1be5b5604bc963254a9f5f76bec6ed23d6a40
Commit Message: support backoff between retries in tcp_proxy
Additional Description: This feature also fixes a bug in the retry
mechanism in tcp proxy in the following situation:
1. We are tunneling TCP over HTTP.
2. A new stream is created on existing upstream connection
(multiplexing) and waiting for response headers.
3. The upstream connection is closed.
4. During the close process, all streams created on this connection will
be reset.
5. The tcp_proxy receives a callback on the stream reset.
6. They retry to connect.
7. The closed connection is picked as it is still in the connection pool
(we are still in the process of the close).
8. The new stream that is created on the second attempt will be reset
immediately.
9. The same process will happen (step 5 - step 8) until we reach the
max_connect_attepts.
10. This means that we are doing only one real attempt in this
situation.
Risk Level: medium
Testing: unit tests, integration tests
Docs Changes: added
Release Notes: added
---------
Signed-off-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Signed-off-by: IssaAbuKalbein <86603440+IssaAbuKalbein@users.noreply.github.com>
Co-authored-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7fa09db1c8cb5e99dc3808d69e7d83276aa9e240
As mentioned in the proposal:
https://github.com/envoyproxy/envoy/issues/35749 , this PR is to support
using Golang to extend TCP upstream proxy, to make changes to
connections and data messages in the http2tcp situation of envoy.
(this PR does)
### Here is my thought about Golang extension function points:
1. Support encoding message processing for upstream TCP requests (route
and cluster have been determined, and targeted message processing can be
performed for route and cluster)
2. Support the handling of conn connection status during the encoding
stage of upstream TCP requests (for example, by setting end_stream=false
to avoid envoy semi connected status)
3. Support decoding message processing and aggregation for upstream TCP
response in onUpstreamData.(for example, by setting end_stream=true to
indicate that the message is encapsulated and can be passed to
downstream)
4. Aggregate the tcp messages received multiple times by onUpstreamData
of tcp response.
5. Support obtaining route and cluster information, which can be
referenced for targeted processing in the above stages.
### What we can do with this Golang extension:
With this golang extension, developers can quickly get started with
envoy and use golang to implement http2tcp such as http2dubbo、http2rpc.
Signed-off-by: duxin40 <duxin40@gamil.com>
Signed-off-by: duxin40 <33946910+duxin40@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ b034c57c7328237a4b12c7d5c2ca41b19569c9b5
Promote envoy.extensions.filters.http.rbac.v3.RBAC.matcher from
`work_in_progress` to stable
Risk Level: Low
Testing: No
Docs Changes: No
Release Notes: No
Signed-off-by: Huabing Zhao <zhaohuabing@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 41d8ccc79c4b98104475b55b5639567b14466190
This PR adds a feature to disable the Envoy DNS query timeout and use
the underlying DNS implementation timeout by setting
`DnsCacheConfig.dns_query_timeout` to 0.
Risk Level: low
Testing: unit and integration test
Docs Changes: inline
Release Notes: inline
Platform Specific Features: dfp
---------
Signed-off-by: Fredy Wijaya <fredyw@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e3246a555ad2b5b25139362deb8f5a35ba1682fe
Make the limit on HTTP/2 metadata configurable. Defaults to the current hardcoded value of 1 MiB.
The value can be configured through a new field on `Http2ProtocolOptions`
Risk Level: Low
Testing: Adds a unit test that covers the new logic in MetadataDecoder
Docs Changes: Added to new proto field but kept hidden to be consistent
with other H2 metadata configuration
---------
Signed-off-by: Jay Dunkelberger <jaydunk@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 98d153be301c16d8329074e31d04b5ac55d268dc
Commit Message: Remove incorrect/outdated doc for explicit_http_config
Additional Description: Per #38064, this docstring became incorrect with
#14362 so should be removed.
Risk Level: None, doc-only.
Testing: n/a
Docs Changes: Yes it is.
Release Notes: n/a
Platform Specific Features: n/a
Signed-off-by: Raven Black <ravenblack@dropbox.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8ded2fefbc1f051a5bf4e18950db2e4bd543014a
Commit Message: OAuth2: Add samesite attribute support for all OAuth2
supported cookie types
Additional Description: The SameSite attribute offers three values to
control whether cookies are shared within the same site or across
different sites. It's an optional setting, with a "Disabled" option that
omits the SameSite attribute altogether. By default, this setting is
disabled to ensure no changes are made to existing deployments, but
operators now have the option to enable SameSite. The six cookies
supporting SameSite attribute are:
bearer_token_cookie
hmac_cookie
expires_cookie
id_token_cookie
refresh_token_cookie
nonce_cookie
The samesite attribute value allowed are:
Strict
Lax
None
Disabled (Default, if no value is set in config)
The operator can also optionally do not specify any SameSite attributes
for cookie. This will result DISABLED value to be set for all cookie's
SameSite attribute value. in this case no same site attribute will be
returned by filter.
The operator can also choose different same site attribute to be
configured by different cookies. This means the SameSite attributes for
different cookies listed above can be different. Also the operator can
optionally specify SameSite attribute for some cookie but miss it for
others. it is not mandatory to specify SameSite explicitly for all
cookies
Risk Level: Medium
Testing: unit
Docs Changes: proto is documented
Release Notes: changelog entry added
---------
Signed-off-by: Yueren Wang <yuerenwang@lyft.com>
Signed-off-by: Yueren Wang <yuerenwang@tm4wwrxcwd.tailbaa43.ts.net>
Co-authored-by: Yueren Wang <yuerenwang@tm4wwrxcwd.tailbaa43.ts.net>
Mirrored from https://github.com/envoyproxy/envoy @ d76115f5eaaa1ee4756d2542762049e1ad1a149e
Commit Message:
Add an UDP sink for HTTP/Transport Tap
Additional Description:
See more detailed information in issue
https://github.com/envoyproxy/envoy/issues/36945
Risk Level: low
Testing:
Manual test has been done
Also CPR test is done
see issue 36945 for more information
Docs Changes:
Build is passed
Release Notes:
Platform Specific Features: N/A
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: fchen7 <cliff.chen@nokia-sbell.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1b5740a76ba69851efa0b1397b8f41b9e60c8d80
## Description
This PR fixes some styling in the RBAC protos and adds the missing
backticks, notes, etc.
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3e5bc7f079b7f9f971cb4002af52d58c5f9f7753
Commit Message: Add filter state IP matcher
Additional Description:
This cl adds a matcher to the generic filter state matcher which
attempts to coerce the specified filter state object into an IP, then
matches it against a configured CIDR range. If the IP is in the range,
the matcher returns true, otherwise false.
Risk Level: low
Testing: unit tested
Docs Changes: none
Release Notes: changelog updated
Platform Specific Features: none
---------
Signed-off-by: antoniovleonti <leonti@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d3e3b35cd8538186d4ccb365f2fa87c9b8567d5e
<!--
!!!ATTENTION!!!
If you are fixing *any* crash or *any* potential security issue, *do
not*
open a pull request in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged
appropriately.
Thank you in advance for helping to keep Envoy secure.
!!!ATTENTION!!!
For an explanation of how to fill out the fields, please see the
relevant section
in
[PULL_REQUESTS.md](https://github.com/envoyproxy/envoy/blob/main/PULL_REQUESTS.md)
-->
Commit Message: Add option to suppress deprecated warning logs.
Additional Description:
This commit introduces a new command-line option
`--suppress-deprecated-warning-logs` that allows users to suppress log
messages related to deprecated fields during Protobuf message
validation. When enabled, Envoy will no longer log warnings for
deprecated fields, which is useful for reducing log verbosity in
production environments. By default, deprecated field warnings are
logged as usual.
Risk Level: Low
Testing: The new option was verified by running Envoy with a static
configuration file. When `--suppress-deprecated-warning-logs` was
enabled, deprecated warning messages were suppressed from the logs, as
expected. Tests also confirm correct log behavior when the option is
toggled.
Docs Changes: yes
Release Notes: yes
Fixes: Addresses issue of reducing log verbosity in production
environments as discussed at #37134
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional [API
Considerations](https://github.com/envoyproxy/envoy/blob/main/api/review_checklist.md):]
---------
Signed-off-by: G Vamshi Krishna Reddy <vamshikrishna.gunreddy@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9c92139dcea0bfc6d355aaf6eeb7987b5ed4a20d
This is a follow up PR for the ext_proc HTTP client support:
https://github.com/envoyproxy/envoy/pull/35676
This PR enables the HTTP service API in the ext_proc filter
configuration.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e2084ce79920723d1eaa1d332ff536cd23b4c49a
## Description
This PR changes the behavior of shadow request sampling so that if trace
sampling is not explicitly configured in the shadow policy, the shadow
request will inherit the parent's sampling decision.
After this change, sampling will follow the trace sampling policy of the
original request, which prevents oversampling when runtime sampling is
disabled.
**Fixes:** #37766
---
**Commit Message:** router: make shadow requests inherit parent sampling
decision by default
**Additional Description:**
**Risk Level:** Low
**Testing:** Added Unit Tests
**Docs Changes:** Added
**Release Notes:** Added
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8e44345df9cf304410112f00b474ed337ac5b395
## Description
Currently, Envoy lacks a straightforward way to create rate limit
descriptors directly from query parameters. The existing
`query_parameter_value_match` action focuses on matching query parameter
values, but does not provide a simple mechanism to generate descriptors.
This PR introduces a new `query_parameters` rate limit action that
allows generating rate limit descriptors based on query parameter
values.
**Fixes:** #37657
---
**Commit Message:** ratelimit: added support for rate limiting based on
query parameters
**Additional Description:**
**Risk Level:** Low
**Testing:** Added Unit Tests
**Docs Changes:** Added
**Release Notes:** Added
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ f39486a9f152d6d6a882291ecdcad2ca390247ce
Commit Message: support backoff between retries in udp_proxy
Additional Description: This feature also fixes a bug in the retry
mechanism in udp proxy in the following situation:
1. We are tunneling UDP over HTTP.
2. A new stream is created on existing upstream connection
(multiplexing) and waiting for response headers.
3. The upstream connection is closed.
4. During the close process, all streams created on this connection will
be reset.
5. The udp_proxy receives a callback on the stream reset.
6. They retry to connect.
7. The closed connection is picked as it is still in the connection pool
(we are still in the process of the close).
8. The new stream that is created on the second attempt will be reset
immediately.
9. The same process will happen (step 5 - step 8) until we reach the
max_connect_attepts.
10. This means that we are doing only one real attempt in this
situation.
Risk Level: medium
Testing: unit tests, integration tests
Docs Changes: added
Release Notes: added
---------
Signed-off-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Co-authored-by: Issa Abu Kalbein <iabukalbein@microsoft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 24254316bab17cb48d48f88297e91a3dee739f58
Reapply the RBAC change by reverting
https://github.com/envoyproxy/envoy/pull/35899.
The original commit is reverted for flaky RBAC integration test.
The fix is pretty simple by just removing the simulated time in the test
([diff](d3297b4aa6)),
I'm not sure of the root cause but the test does not really need the
simulated test.
Before the fix, the flaky test can be reproduced easily with
`--runs_per_test=1000`, After the test, I can no longer reproduce
the failure. To be on the safer side, I ran the test with
`--runs_per_test=10000` and still couldn't reproduce the test failure.
Test output:
```
% bazel test //test/extensions/filters/network/rbac:integration_test --runs_per_test=10000 --test_timeout=60 --test_env=ENVOY_IP_TEST_VERSIONS=v4only
INFO: Invocation ID: c1ebbc18-4887-4626-9d19-e257d42fe4cd
INFO: Analyzed target //test/extensions/filters/network/rbac:integration_test (0 packages loaded, 19 targets configured).
INFO: Found 1 test target...
Target //test/extensions/filters/network/rbac:integration_test up-to-date:
bazel-bin/test/extensions/filters/network/rbac/integration_test
INFO: Elapsed time: 2486.472s, Critical Path: 24.73s
INFO: 10001 processes: 1 internal, 10000 processwrapper-sandbox.
INFO: Build completed successfully, 10001 total actions
Executed 1 out of 1 test: 1 test passes.
```
---------
Signed-off-by: Yangmin Zhu <ymzhu@uber.com>
Mirrored from https://github.com/envoyproxy/envoy @ 72854250164014b5b179ee5c9b4c4b88d8bba38c
Created by Envoy dependency bot for @phlaxFix#37778
Signed-off-by: dependency-envoy[bot] <148525496+dependency-envoy[bot]@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2aa8a14d646234c36c9a8267a3caeb5485501001
Commit Message: xDS: add enum specified in xRFC TP3 in the right place
Additional Description: In #37818, I incorrectly added this new value to
the deprecated location for this enum, not the real location. :(
Risk Level: Low
Testing: N/A
Docs Changes: Included in PR
Release Notes: N/A
Platform Specific Features: N/A
CC @adisuissa
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f7a86358aeaa1627c43da8ebfddb9a94d525166a
## Description
This PR adds some more description around `use_independent_randomness`
to make it more user-friendly and clarify other fields.
<img width="991" alt="Screenshot 2024-12-23 at 01 20 20"
src="https://github.com/user-attachments/assets/5d1a1532-3f47-49bc-87c0-cf5189a2877f"
/>
---
**Commit Message:** docs: clarify the docs on runtime_filter
**Additional Description:** Added some more description around
`use_independent_randomness` to make it more user-friendly.
**Risk Level:** Very Low
**Testing:** N/A
**Docs Changes:** N/A
**Release Notes:** N/A
---------
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ f1228663ff631ea95ef7d464de6efa898fbd430a
Commit Message: ratelimit: option to excute action on stream done
Additional Description:
This adds a new option `apply_on_stream_done` to the rate limit
policy corresponding to each descriptor. This basically allows to
configure
descriptors to be executed in a response content-aware way and do not
enforce the rate limit (in other words "fire-and-forget"). Since addend
can be currently controlled via metadata per descriptor,
another filter can be used to set the value to reflect their intent
there,
for example, by using Lua or Ext Proc filters.
This use case arises from the LLM API services which usually return
the usage statistics in the response body. More specifically,
they have "streaming" APIs whose response is a line-by-line event
stream where the very last line of the response line contains the
usage statistics. The lazy nature of this action is perfectly fine
as in these use cases, the rate limit happens like "you are forbidden
from the next time".
Besides the LLM specific, I've also encountered the use case from the
data center resource allocation case where the operators want to
"block the computation from the next time since you used this much
resources in this request".
Ref: https://github.com/envoyproxy/gateway/issues/4756
Risk Level: low
Testing: done
Docs Changes: done
Release Notes: TODO
Platform Specific Features: n/a
---------
Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 857107b72abdf62690b7a1c69f9a3684d57f5f3e
Commit Message: api: new per descriptor hits-addend support and dynamic
hits addend
Additional Description:
1. Now, we could get custom hits_addend from the
`envoy.ratelimit.hits_addend`. But if there are multiple rate limit
filters that requrie custom hits_addend, the
`envoy.ratelimit.hits_addend` couldn't meet the requirement.
2. And we cann't also to support different hits_addend for diffferent
descriptots in same request.
This API changes try to meet above two requirements.
Risk Level: low.
Testing: n/a.
Docs Changes: n/a.
Release Notes: n/a.
Platform Specific Features: n/a.
---------
Signed-off-by: wangbaiping(wbpcode) <wangbaiping@bytedance.com>
Mirrored from https://github.com/envoyproxy/envoy @ cac9b87e9c0cd10eafc64817130c27c567395f4d
update-envoy[bot]