grpcwebproxy: Delayed leading headers in bidir streaming rpcs on websocket transport #791
Description
Versions of relevant software used
go get -u github.com/improbable-eng/grpc-web/go/grpcwebproxy
@improbable-eng/grpc-web": "^0.13.0
ts-protoc-gen": "^0.13.0
What happened
When using the websocket transport, on a bidirectional streaming RPC where the server explicitly sends metada before any message, grpcwebproxy will delay the dispatching of the metadata until the first message is sent.
What you expected to happen
I would expect the metadata to be dispatched immediately.
How to reproduce it (as minimally and precisely as possible):
On the grpc backend:
func bidirstreamhandler(srv pb.Service_MethodServer) error {
// Send leading metadata
meta := make(map[string][]string)
meta["key"] = append(meta["key"], "value")
srv.SendHeader(meta)
// swallow messages until the client gives up
for {
in, err := srv.Recv()
if err != nil {
break
}
// Only send a message once something has been received.
srv.Send(&pb.ReplyMessage{})
}
return nil
}
On the client:
const ws_transport = grpc.WebsocketTransport();
grpc.setDefaultTransport(ws_transport);
const msgStream = grpc.client(Service.Method, {host: getGrpcHost()})
msgStream.onHeaders((headers) => {
// Only send messages once headers have been received. Deadlock!
msgStream.send(new pb.Request())
})
msgstream.start()
Anything else we need to know
I have confirmed that the backend does send the headers when a golang grpc client uses the service.
I have also confirmed that the browser does not receive any websocket message.
I have not tested this on either unary, unary-stream or stream-unary methods, and am not 100% certain what the expected behavior would be.
Obviously, this can be easily worked around by sending and cleanly handling noop messages, but I shouldn't have to do this :)