Repository: envoyproxy/envoy
File: api/envoy/extensions/filters/http/ext_proc/v3/processing_mode.proto (Protocol Buffers)

Code before:
    //   to true as part of the last body chunk request to notify the server that no other data is to be sent.
    // * The server needs to send
    //   :ref:`StreamedBodyResponse <envoy_v3_api_msg_service.ext_proc.v3.StreamedBodyResponse>`
    //   to the client in the body response.
    // * The client will stream the body chunks in the responses from the server to the upstream/downstream as they arrive.

    FULL_DUPLEX_STREAMED = 4;

    // [#not-implemented-hide:]
    // gRPC traffic. In this mode, the ext_proc client will de-frame the
    // individual gRPC messages inside the HTTP/2 DATA frames, and as each
    // message is de-framed, it will be sent to the ext_proc server as a
    // :ref:`request_body
    // <envoy_v3_api_field_service.ext_proc.v3.ProcessingRequest.request_body>`
    // or :ref:`response_body
    // <envoy_v3_api_field_service.ext_proc.v3.ProcessingRequest.response_body>`.
    // The ext_proc server will stream back individual gRPC messages in the
    // :ref:`StreamedBodyResponse <envoy_v3_api_msg_service.ext_proc.v3.StreamedBodyResponse>`
    // field, but the number of messages sent by the ext_proc server
    // does not need to equal the number of messages sent by the data
    // plane.  This allows the ext_proc server to change the number of
    // messages sent on the stream.
    // In this mode, the client will send body and trailers to the server as
    // they arrive.
    GRPC = 5;
  }

  // How to handle the request header. Default is "SEND".
  // Note this field is ignored in :ref:`mode_override
  // <envoy_v3_api_field_service.ext_proc.v3.ProcessingResponse.mode_override>`, since mode
  // overrides can only affect messages exchanged after the request header is processed.
  HeaderSendMode request_header_mode = 1 [(validate.rules).enum = {defined_only: true}];

  // How to handle the response header. Default is "SEND".
  HeaderSendMode response_header_mode = 2 [(validate.rules).enum = {defined_only: true}];

  // How to handle the request body. Default is "NONE".
  BodySendMode request_body_mode = 3 [(validate.rules).enum = {defined_only: true}];

  // How do handle the response body. Default is "NONE".
  BodySendMode response_body_mode = 4 [(validate.rules).enum = {defined_only: true}];

  // How to handle the request trailers. Default is "SKIP".
  HeaderSendMode request_trailer_mode = 5 [(validate.rules).enum = {defined_only: true}];

  // How to handle the response trailers. Default is "SKIP".
  HeaderSendMode response_trailer_mode = 6 [(validate.rules).enum = {defined_only: true}];
}


Review comment (suggestion):
This protocol mode does not seem to define a new behavior but rather a semantic interpretation of content of the body bytes. An ext_proc client that sends a `body` containing a complete gRPC message using the GRPC mode and any other mode is indistinguishable to the ext_proc server - i.e. they will all be processed the same way. 

In the end I think this change complicates the already complicated and confusing protocol even more without offering a tangible benefit. More over server implementations still have to support gRPC messages split over multiple ext_proc messages since this is an existing behavior. 

Code after:
    //   to true as part of the last body chunk request to notify the server that no other data is to be sent.
    // * The server needs to send
    //   :ref:`StreamedBodyResponse <envoy_v3_api_msg_service.ext_proc.v3.StreamedBodyResponse>`
    //   to the client in the body response.
    // * The client will stream the body chunks in the responses from the server to the upstream/downstream as they arrive.

    FULL_DUPLEX_STREAMED = 4;

    // [#not-implemented-hide:]
    // A mode for gRPC traffic. This is similar to ``FULL_DUPLEX_STREAMED``,
    // except that instead of sending raw chunks of the HTTP/2 DATA frames,
    // the ext_proc client will de-frame the individual gRPC messages inside
    // the HTTP/2 DATA frames, and as each message is de-framed, it will be
    // sent to the ext_proc server as a :ref:`request_body
    // <envoy_v3_api_field_service.ext_proc.v3.ProcessingRequest.request_body>`
    // or :ref:`response_body
    // <envoy_v3_api_field_service.ext_proc.v3.ProcessingRequest.response_body>`.
    // The ext_proc server will stream back individual gRPC messages in the
    // :ref:`StreamedBodyResponse <envoy_v3_api_msg_service.ext_proc.v3.StreamedBodyResponse>`
    // field, but the number of messages sent by the ext_proc server
    // does not need to equal the number of messages sent by the data
    // plane.  This allows the ext_proc server to change the number of
    // messages sent on the stream.
    // In this mode, the client will send body and trailers to the server as
    // they arrive.
    GRPC = 5;
  }

  // How to handle the request header. Default is "SEND".
  // Note this field is ignored in :ref:`mode_override
  // <envoy_v3_api_field_service.ext_proc.v3.ProcessingResponse.mode_override>`, since mode
  // overrides can only affect messages exchanged after the request header is processed.
  HeaderSendMode request_header_mode = 1 [(validate.rules).enum = {defined_only: true}];

  // How to handle the response header. Default is "SEND".
  HeaderSendMode response_header_mode = 2 [(validate.rules).enum = {defined_only: true}];

  // How to handle the request body. Default is "NONE".
  BodySendMode request_body_mode = 3 [(validate.rules).enum = {defined_only: true}];

  // How do handle the response body. Default is "NONE".
  BodySendMode response_body_mode = 4 [(validate.rules).enum = {defined_only: true}];

  // How to handle the request trailers. Default is "SKIP".
  HeaderSendMode request_trailer_mode = 5 [(validate.rules).enum = {defined_only: true}];

  // How to handle the response trailers. Default is "SKIP".
  HeaderSendMode response_trailer_mode = 6 [(validate.rules).enum = {defined_only: true}];
}