envoyproxy / envoyproxy/envoy

[ext_proc] add disallowed_mode in mode overrides, ignore/filter forbidden send-events or reject the whole processingMode, without configuring envoy with all the possible allowed send-event combinations

Open
#38,273 6 comments 0 reactions 0 assignees View on GitHub
area/ext_proc enhancement no stalebot
Dominant language
C++
Stars
28.9k
Forks
5.6k
Avg merge
1d 20h
Merged PRs (30d)
437

Description

*Title*: [ext_proc] add disallowed_mode in mode overrides, ignore/filter forbidden send-events or reject the whole processingMode, without configuring envoy with all the possible allowed send-event combinations

*Description*:

When mode override is enabled with allowed_override_modes, mode_override from xxHeader Response is matched against a list of valid modes.
https://github.com/envoyproxy/envoy/blob/main/source/extensions/filters/http/ext_proc/ext_proc.cc#L1241-L1246
Envoy has to have all the possible valid combinations of "{request/response}x{_headers, _mode, _trailers}" such that it won't reject a ProcessingMode returned by remote extproc server, up to 3x5x3x3x5x3 of them.

Let's add a filtering mechanism, instead of iterating all the combinations, upon receiving a ProcessingMode, apply overriding on a per-event basis,
e.g.
"allowed_response_header_modes: [SEND]" ==> ProcessingResponse::mode_override::response_header_mode could be either [DEFAULT(no-update); SKIP; SEND]
"allowed_response_body_modes: [STREAMED, NONE, BUFFERED]" ==> then ProcessingResponse::mode_override::request_body_mode could be either/and-only [STREAMED, NONE, BUFFERED].

In addition, we should ignore phases that has "passed" in the mode comparison: if it's a ResponseHeader ProcessingResponse, no need to(ignore) all the request_xxx modes field.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.