grpc-web: Response parsing breaks with 'grpc-encoding: gzip'
When the gRPC response is gzipped (indicated by the grpc-encoding: gzip
response header), the grpc-web stream parser fails with this error (including the first few bytes for reference):
Uncaught Error: The stream is broken @0/0. Error: invalid frame byte. With input:
1,0,0,2,126,31,...
And the grpc-web filter in Envoy unfortunately automatically adds this request header when proxying to the gRPC server: grpc-accept-encoding:identity,deflate,gzip
, which in the case of akka-grpc at least causes the server to gzip. The envoy source code has a comment stating that this header ‘is required for gRPC’.
When I hacked akka-grpc to ignore the above header and not gzip, the response is properly parsed.
I’m a backend engr., but if someone can give me some pointers I could take a stab at fixing this.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Reactions: 6
- Comments: 16
@stanley-cheung We are also facing similar issue with gzip compression not supported by grpc-web. Issue #1000 The protobuf payload is larger than the gzipped JSON payload and this adds to the increased response time. We are not able to move to grpc-web currently for our JS client to service calls due to this issue.
Any plans you could share on this gzip support being added in the near future? Or any other suggestions in terms of other compression that grpc-web supports or ways to mitigate the issue?
This cost me some hours. Here is a solution, a bit of code to get others started that run into this issue with Akka HTTP:
According to this, seems like such compression is redundant. With envoy you can use
request_headers_to_remove
(doc) or this to completely remove or modify this header.