grpcurl icon indicating copy to clipboard operation
grpcurl copied to clipboard

No EOS sent for ServerReflectionInfo request

Open laurentvaills opened this issue 4 years ago • 5 comments

While working with grpcurl with some HTTP/2 proxies between grpcurl and the gRPC server, I noticed that for the following request:

$ grpcurl -v -plaintext -d '{"name": "Laurent"}' localhost:8080 helloworld.Greeter/SayHello

grpcurl actually sends 2 requests:

  • a first one to /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo (to get the proto definition if I'm right)
  • a second one which is the actual call to the requested service /helloworld.Greeter/SayHello

But I noticed that the first request does not send the EOS (End Of Stream) flag . So if the proxy in between, instead of streaming directly the incoming request, buffers the request (for whatever reason), it waits indefinitely for the EOS flag.

Based on the following document https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md I think the DATA frame of the ServerReflectionInfo request should be flagged with END_STREAM.

laurentvaills avatar Oct 06 '20 20:10 laurentvaills

From what I noticed with Wireshark, it seems that grpcurl end a DATA frame flagged with EOS on the stream id that the stream used for ServerReflectionInfo at the very end (after having received the response for SayHello), which is too late.

laurentvaills avatar Oct 07 '20 04:10 laurentvaills

@laurentvaills, grpcurl uses the reflection service correctly. Setting EOS would mean it's issuing two different RPCs, one for each request. However, the reflection service is a bidi streaming endpoint, kind of like a web socket. The client can keep the stream open and issue multiple requests, interleaved with receiving response messages from the server.

So the actual behavior for the reflection client is to send a message, then wait for the server's response. Then the client can send more requests on the same stream (and get subsequent response messages from the server). So it is working as intended.

But HTTP 1.1 does not support bidi streaming -- it is a feature of HTTP/2. Is it possible the proxy that is buffering the data (waiting indefinitely for more data or for the stream to be half-closed) is an HTTP 1.1 proxy?

jhump avatar Apr 29 '21 14:04 jhump