Response not parsed ok, missing grpc-status according to error, but WireShark show the status in response

[maloo]

Versions of relevant software used "@improbable-eng/grpc-web": "^0.13.0" "ts-protoc-gen": "^0.14.0"

What happened I have a grpc-web service that I call from typescript using improbable grpc generated client code. But all calls return error message: "Response closed without grpc-status (Headers only)", code: 2 The exact same server works fine with dotnet grpc-web client and standard protoc TS+JS client. But since the standard client doesn't support message streams where each message is sent as chunked encoding (long polling events) I had to try the improbable grpc-web TS client. But then not even normal unary calls works anymore.

What you expected to happen The improbable grpc-web service code should return a valid response instead of an error in the service callback.

How to reproduce it (as minimally and precisely as possible): Try to parse the below response. Or point out what is wrong in the response (that at least two other frameworks parse ok).

Full logs to relevant components Here is the complete response from the server, captured by wire shark: Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1 Transmission Control Protocol, Src Port: 5050, Dst Port: 52461, Seq: 175, Ack: 383, Len: 5 [2 Reassembled TCP Segments (179 bytes): #97392(174), #97394(5)] Hypertext Transfer Protocol HTTP/1.1 200 OK\r\n Date: Thu, 17 Dec 2020 21:50:48 GMT\r\n Content-Type: application/grpc-web\r\n Server: Kestrel\r\n Transfer-Encoding: chunked\r\n \r\n [HTTP response 1/1] [Time since request: 1.099601000 seconds] [Request in frame: 97167] [Request URI: http://localhost:5050/***] HTTP chunked response Data chunk (5 octets) Chunk size: 5 octets Data (5 bytes) Data: 0000000000 [Length: 5] Chunk boundary: 0d0a Data chunk (21 octets) Chunk size: 21 octets Data (21 bytes) Data: 8000000010477270632d5374617475733a20300d0a [Length: 21] Chunk boundary: 0d0a End of chunked encoding Chunk size: 0 octets \r\n File Data: 26 bytes Media Type Media type: application/grpc-web (26 bytes)

0000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK. 0010 0a 44 61 74 65 3a 20 54 68 75 2c 20 31 37 20 44 .Date: Thu, 17 D 0020 65 63 20 32 30 32 30 20 32 31 3a 35 30 3a 34 38 ec 2020 21:50:48 0030 20 47 4d 54 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 GMT..Content-Ty 0040 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f pe: application/ 0050 67 72 70 63 2d 77 65 62 0d 0a 53 65 72 76 65 72 grpc-web..Server 0060 3a 20 4b 65 73 74 72 65 6c 0d 0a 54 72 61 6e 73 : Kestrel..Trans 0070 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20 63 68 fer-Encoding: ch 0080 75 6e 6b 65 64 0d 0a 0d 0a 35 0d 0a 00 00 00 00 unked....5...... 0090 00 0d 0a 31 35 0d 0a 80 00 00 00 10 47 72 70 63 ...15.......Grpc 00a0 2d 53 74 61 74 75 73 3a 20 30 0d 0a 0d 0a 30 0d -Status: 0....0. 00b0 0a 0d 0a ...

Anything else we need to know

Environment:

• OS (e.g. from /etc/os-release): Windows 10
• Kernel (e.g. uname -a):
• Others: Running in electron (VScode extension)
• Server is dotnet 5, aspdotnet core grpc-web

[johanbrandhorst]

Hi Marcus, I'm having a bit of trouble understanding exactly what the issue is here, is it a problem with the grpc-web client or the grpc-web proxy? What language is the backend gRPC server written in and what proxy are you using?

[maloo]

It is the client generated by ts-protoc-gen that can't parse the server response. As you can see under environment I use a Asp. net core 5 grpc server. This server can handle both grpc and grpc-web natively.