Istio 1.16下Envoy ext_proc过滤器SKIP响应trailer时无法触发EOF求助

问题背景 #

使用Istio 1.16（搭配Envoy v1.24.1 sidecar）配置ext_proc v3过滤器，通过gRPC连接远程API，需要在每个请求完成后发送健康信息。当前ext_proc处理模式配置如下：

request_header_mode: "SEND"
response_header_mode: "SEND"
request_body_mode: "BUFFERED"
response_body_mode: "BUFFERED"
request_trailer_mode: "SKIP"
response_trailer_mode: "SKIP"

该配置下，gRPC服务端的Recv()方法无法触发io.EOF，上下文也不会取消，导致EOF分支中发送远程API请求的代码无法执行。但将response_trailer_mode改为SEND后，流会正常关闭并触发EOF，然而业务场景不需要响应Trailer，希望保持SKIP模式。

问题原因 #

ext_proc v3协议中，当response_trailer_mode设为SKIP时，Envoy不会向ext_proc服务端发送响应Trailer的结束信号，也不会主动关闭双向gRPC流。服务端会一直处于等待接收消息的状态，无法触发io.EOF。而设置为SEND时，Envoy会发送一个空的Trailer帧来标记流结束，从而触发EOF并取消上下文。

解决方案 #

既然配置了response_body_mode: "BUFFERED"，Envoy会将整个响应体一次性发送给ext_proc服务端，因此可以通过检测响应体处理完成的事件来替代等待EOF，具体实现如下：

修改服务端代码逻辑 #

不再依赖io.EOF触发远程API调用，而是在收到ResponseBody消息时，判定当前请求的所有处理阶段已完成，直接执行远程API调用并结束流：

import (
    "io"
    "google.golang.org/grpc/codes"
    "google.golang.org/grpc/status"
    ext_proc_v3 "github.com/envoyproxy/envoy/contrib/golang/filters/http/source/extproc/service"
)

func (s *server) Process(srv ext_proc_v3.ExternalProcessor_ProcessServer) error {
    ctx := srv.Context()
    var processedResponseBody bool

    for {
        select {
        case <-ctx.Done():
            // 上下文取消时，确保执行远程API调用
            sendRequestToRemoteAPI()
            return ctx.Err()
        default:
        }

        req, err := srv.Recv()
        if err == io.EOF {
            // 兼容response_trailer_mode为SEND的情况
            sendRequestToRemoteAPI()
            return nil
        }
        if err != nil {
            return status.Errorf(codes.Unknown, "cannot receive stream request: %v", err)
        }

        // 处理不同类型的请求消息
        switch msg := req.Request.(type) {
        case *ext_proc_v3.ExternalProcessorRequest_RequestHeaders:
            // 处理请求头逻辑
        case *ext_proc_v3.ExternalProcessorRequest_RequestBody:
            // 处理请求体逻辑
        case *ext_proc_v3.ExternalProcessorRequest_ResponseHeaders:
            // 处理响应头逻辑
        case *ext_proc_v3.ExternalProcessorRequest_ResponseBody:
            // 处理响应体逻辑
            processedResponseBody = true
            // 响应体已全部接收，请求处理完成，触发远程API调用
            sendRequestToRemoteAPI()
            // 结束流，无需继续等待
            return nil
        }
    }
}

func sendRequestToRemoteAPI() {
    // 发送健康信息到远程API的实现
}

方案说明 #

1. 因为response_body_mode是BUFFERED，Envoy会一次性发送完整的响应体，收到ResponseBody消息即代表当前请求的所有需要处理的阶段（请求头、请求体、响应头、响应体）已完成。
2. 同时保留了对io.EOF的处理，兼容后续可能修改response_trailer_mode为SEND的场景。
3. 监听上下文Done()信号，避免因异常取消导致远程API调用遗漏。

内容的提问来源于stack exchange，提问作者John