A93: xDS ExtProc Support by markdroth · Pull Request #484 · grpc/proposal

markdroth · 2025-03-13T20:42:43Z

No description provided.

Adds a new body send mode for gRPC traffic. Also adds a safe way for the ext_proc server to return OK status without losing data in FULL_DUPLEX_STREAMED and GRPC modes. See grpc/proposal#484 for context. Risk Level: Low Testing: N/A Docs Changes: Included in PR Release Notes: N/A Platform Specific Features: N/A --------- Signed-off-by: Mark D. Roth <roth@google.com> Co-authored-by: Adi (Suissa) Peleg <adip@google.com>

Adds a new body send mode for gRPC traffic. Also adds a safe way for the ext_proc server to return OK status without losing data in FULL_DUPLEX_STREAMED and GRPC modes. See grpc/proposal#484 for context. Risk Level: Low Testing: N/A Docs Changes: Included in PR Release Notes: N/A Platform Specific Features: N/A --------- Signed-off-by: Mark D. Roth <roth@google.com> Co-authored-by: Adi (Suissa) Peleg <adip@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 7b3a632333b587c784aff65e72ff618ff034f331

A93-xds-ext-proc.md

dfawley · 2026-02-12T21:53:12Z

A93-xds-ext-proc.md

+- [request_headers](https://github.com/envoyproxy/envoy/blob/cdd19052348f7f6d85910605d957ba4fe0538aec/api/envoy/service/ext_proc/v3/external_processor.proto#L76)
+  and
+  [response_headers](https://github.com/envoyproxy/envoy/blob/cdd19052348f7f6d85910605d957ba4fe0538aec/api/envoy/service/ext_proc/v3/external_processor.proto#L81).
+  Populated when sending client headers or server headers, respectively.


I know we talked about this, but what's the story around what headers should be included vs. not? Are we going to define which headers specifically? It would be good to call out exactly whether method/scheme/path/te/user-agent/message-type/etc, etc are supposed to be included or not. In Go many of these things are added by the transport on the way out or are removed by the transport on the way in. It would be great if we can specify: "only the things set by the application [plus X, Y, and Z, which some libraries may need to manually synthesize before sending to the ext_proc server]"

Yeah, we need to add this for both ext_authz and ext_proc. I think @easwars was compiling a list of what headers we should document.

A93-xds-ext-proc.md

dfawley · 2026-02-12T22:09:18Z

A93-xds-ext-proc.md

+          If true, indicates that a half-close should be sent after the
+          message.  Honored only on client-to-server messages.


This puts the stream into an interesting state where the client application may continue sending messages but the filter needs to ignore them. In Go, on the client, it can simply ignore calls to SendMsg(), but on the server (in all languages with a blocking API, so maybe just Go/Rust?), it means we need to spawn a job to read from the client send stream and discard the results so the client doesn't block on flow control.

Actually in Rust we may implement it a bit differently, at least with my current design -- we would be giving the handler an owned RecvStream to poll and the gRPC library will already have to handle the situation where the application drops it early before returning from the handler -- in that case, we probably want to do this behavior of discarding any received messages vs. the alternative of letting the client application back up on flow control.

(I assume it's better to drain it, otherwise it could lead to deadlocks.)

Yes, I think we need to drain it for flow control reasons.

This seems like mostly a comment about the implementation, not the gRFC, so let's discuss further offline if needed.

This is going to apply to all implementations, though, so I think it's important to mention it here -- half-close is normally initiated by the client, but in this case the server is simulating it with no way to signal it is doing so to the client. So servers need to make sure they continue to read from the request stream and discard anything received.

dfawley · 2026-02-12T22:17:08Z

A93-xds-ext-proc.md

+
+#### Server-Side Metrics
+
+The following server-side metrics will be exported:


Are there no labels that could be used on the server?

Not that I can think of. If you have any suggestions of labels that you think might be useful here, I'm open to them.

Aren't these actually per-call/attempt metrics, so should they have all the same labels as the default per-call metrics?

A93-xds-ext-proc.md

dfawley · 2026-02-23T21:56:19Z

A93-xds-ext-proc.md

+
+### Metrics
+
+The ext_authz filter will export metrics using the non-per-call metrics


ext_proc?

dfawley · 2026-02-23T21:56:26Z

A93-xds-ext-proc.md

+| grpc.target | required | The target of the gRPC channel in which ext_authz is used, as the defined in [A66]. |
+| grpc.lb.backend_service | optional | The backend service to which the traffic is being sent, as defined in [A89].  This will be populated from the xDS cluster name, which will be passed to the ext_authz filter as described in [A60]. |


ext_proc x2

dfawley · 2026-02-23T21:56:58Z

A93-xds-ext-proc.md

+The ext_authz filter will export metrics using the non-per-call metrics
+architecture defined in [A79].  There will be a separate set of metrics


Oh maybe the implication is that it will get all of those labels already? If so we should call that out, probably?

dfawley · 2026-02-23T21:57:10Z

A93-xds-ext-proc.md

+difference to the ext_proc server, we have added a new field called
+`grpc_message_compressed` in both the ext_proc request and response
+message (see https://github.com/envoyproxy/envoy/pull/38753).  Envoy
+will set this bit in the ext_authz request based on the corresponding


dfawley · 2026-02-23T21:57:18Z

A93-xds-ext-proc.md

+- message_timeout and max_message_timeout: Message timeouts do not make
+  sense in GRPC body send mode.
+- http_service: It doesn't make sense for gRPC to support non-gRPC
+  mechanisms for contacting the ext_authz server.


dfawley · 2026-02-23T21:58:36Z

A93-xds-ext-proc.md

+  and
+  [response_body](https://github.com/envoyproxy/envoy/blob/cdd19052348f7f6d85910605d957ba4fe0538aec/api/envoy/service/ext_proc/v3/external_processor.proto#L89).
+  Populated when sending a client message or server message, respectively.
+  Inside of them:


Have we talked about the performance implications here? If Go uses its current interceptor API, then we'll have only deserialized messages available, meaning we'll have to re-serialize when sending to the ext_proc server. So in theory we're burning extra CPU than if we could just take the payload straight from the bytes and set them in the body field.

markdroth added 20 commits March 12, 2025 23:43

WIP

8028bf3

more WIP

7a9afce

nail down some details

bb9125a

reference A102

c90bc7d

flow control for o11y mode

634cfec

added a lot more details, and a lot of TODOs

85de0ec

lots more details

8a9fefc

fix section header scope

be854e0

trace context

1d9e41d

flow control, and remove event list

15ad179

no message timeout

f99a868

add TODO about metrics

08230f0

avoid the need for flow control by using full duplex streaming

ba1133a

use streamed body response, and add request_drain field

3849858

flesh out metrics

1a896bb

fix typo

e532a11

add end_of_stream_without_message fields

0807986

move metrics section

ccaee21

spell out drain workflow

51add0a

document filter state retention

f483125

markdroth mentioned this pull request Sep 18, 2025

xDS: ext_proc: add GRPC body send mode envoyproxy/envoy#38753

Merged

markdroth marked this pull request as ready for review September 18, 2025 22:50

markdroth requested review from dfawley and ejona86 September 18, 2025 22:50

markdroth added 6 commits September 18, 2025 22:58

add mailing list link

3404ced

improve description of body send mode

17a8fe4

document interaction with compression

376ecd7

fix typo

e2da6bd

refer back to A92 for header rewriting

ef27648

refer to A92 also for header mutation rules

36fb214

separate env var guards on client and server side

9f70143

markdroth mentioned this pull request Dec 24, 2025

A110: Child Channel Options #529

Open

dfawley reviewed Feb 12, 2026

View reviewed changes

markdroth added 2 commits February 20, 2026 21:41

don't support separate grpc_initial_metadata field in override config

4d9a7fb

address dfawley comments

f8ade5b

markdroth mentioned this pull request Feb 21, 2026

[xDS] ext_proc filter grpc/grpc#41704

Draft

easwars mentioned this pull request Feb 23, 2026

Public Extension API for Custom xDS HTTP Filters in grpc-go grpc/grpc-go#8934

Closed

dfawley reviewed Feb 23, 2026

View reviewed changes

		If true, indicates that a half-close should be sent after the
		message. Honored only on client-to-server messages.


		#### Server-Side Metrics

		The following server-side metrics will be exported:


		### Metrics

		The ext_authz filter will export metrics using the non-per-call metrics

		\| grpc.target \| required \| The target of the gRPC channel in which ext_authz is used, as the defined in [A66]. \|
		\| grpc.lb.backend_service \| optional \| The backend service to which the traffic is being sent, as defined in [A89]. This will be populated from the xDS cluster name, which will be passed to the ext_authz filter as described in [A60]. \|

		The ext_authz filter will export metrics using the non-per-call metrics
		architecture defined in [A79]. There will be a separate set of metrics

Conversation

markdroth commented Mar 13, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants