grpc-web RPC blocks forever if gRPC server terminates #13831
Description
If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-security@googlegroups.com where the issue will be triaged appropriately.
Title: grpc-web RPC blocks forever if gRPC server terminates
Description:
I have a gRPC-web client and a C++ gRPC server. When using envoy v1.14, if a gRPC server died, the invocation of an RPC from the client side would throw an exception. In envoy v1.16, the RPC instead blocks forever, which is undesirable.
My config:
admin:
access_log_path: /dev/stdout
address:
socket_address: { address: 0.0.0.0, port_value: 9902 }
static_resources:
listeners:
- name: listener_0
address:
socket_address:
{ address: 0.0.0.0, port_value: "8080" }
filter_chains:
- filters:
- name: envoy.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.config.filter.network.http_connection_manager.v2.HttpConnectionManager
codec_type: auto
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match: { prefix: "/my.package" }
route:
cluster: gprc_server
max_grpc_timeout: 0s
cors:
allow_origin_string_match:
- prefix: "*"
allow_methods: GET, PUT, DELETE, POST, OPTIONS
allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,custom-header-1,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout
max_age: "1728000"
expose_headers: custom-header-1,grpc-status,grpc-message
http_filters:
- name: envoy.filters.http.grpc_web
- name: envoy.filters.http.cors
- name: envoy.filters.http.router
clusters:
- name: gprc_server
connect_timeout: 0.25s
type: logical_dns
http2_protocol_options: {}
lb_policy: round_robin
load_assignment:
cluster_name: gprc_server
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: gprc_server
port_value: "7000"
layered_runtime:
layers:
- name: static_layer_0
static_layer:
overload:
global_downstream_max_connections: 50000
I noticed that the v1.16 release notes state that:
"http: changed how local replies are processed for requests which transform from grpc to not-grpc, or not-grpc to grpc. Previously the initial generated reply depended on which filter sent the reply, but now the reply is consistently generated the way the downstream expects. This behavior can be temporarily reverted by setting envoy.reloadable_features.unify_grpc_handling to false."
If i set envoy.reloadable_features.unify_grpc_handling to false, this issue goes away.