When handle unary grpc requests, it seems End-of-Stream is not neccesary, why?

[rinfx]

When I use grpc to handle unary rpc requests, I found even the data frame don't have the flag End-of-Stream, requests will also be processed. I comment line 793 ~ 797, and find the server can process requests normally. That indicates the go-grpc server don't rely on End-of-Stream to mark the end of a request. Why? https://github.com/grpc/grpc-go/blob/dbbcf59957fec0bd58063224cbf105b3b3698d4e/internal/transport/http2_server.go#L773-L797

[rinfx]

Dose this behavior conform to the RPC Protocol ?

For requests, EOS (end-of-stream) is indicated by the presence of the END_STREAM flag on the last received DATA frame. In scenarios where the Request stream needs to be closed but no data remains to be sent implementations MUST send an empty DATA frame with this flag set.

[arvindbr8]

the go-grpc server don't rely on End-of-Stream to mark the end of a request.

This is only true in the case of Unary RPCs. EOS flag only marks the end of a request only in the case of client / BiDi streaming RPCs. EOS flag set on the frame by the client should not impact the server behavior in all the other types.

[dfawley]

This isn't exactly as I would have said it.

The behavior you're seeing is what the server is doing. The server is programmed with the knowledge that you are doing a unary RPC, which means it can send the response message and trailers without waiting for the client to send an end-stream flag anywhere. The client still should always perform the end-stream to conform to the spec, but for unary RPCs, the server does not require them.

[arvindbr8]

Thanks for clarifying @dfawley.

@rinfx FYI this is the protocol doc that is up to date - https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md