Gzip compression in response from gRPC-java to gRPC-web

70 views
Skip to first unread message

Danil Vilnikov

unread,
Jul 20, 2022, 10:51:34 AMJul 20
to grpc.io
Hi Team!

I am using gRPC-java on server side and gRPC-web on client. And I want to compress my response messages.
In first case I send Metadata {'grpc-accept-encoding': 'gzip'} from client and call setCompressed("gzip") method on server side. But when I send compressed response my client fall with error 'Error in parsing response body'. And my response payload don't decompress with another gzip decompressors.
In second case I try to push header "Content-Encryption" with value "gzip" into response and set method setCompressor("gzip") on server-side. But I get "(failed)
net::ERR_CONTENT_DECODING_FAILED" on response status. 

How can I send compressed responses and proceed them on client?

Eryu Xia

unread,
Jul 27, 2022, 5:58:17 PMJul 27
to grpc.io
Hi!

Without having any background knowledge, it seems that according to this page (https://github.com/grpc/grpc-web/blob/master/doc/browser-features.md#compression), it sounds like compression should be enabled by default.

Curious what grpc-web proxy are you using? AFAIU grpc-web should terminate at the proxy and any compression flags should be set there instead (if necessary)?

thanks!

Akshay Shah

unread,
Jul 28, 2022, 11:05:18 AMJul 28
to grpc.io
Danil,

As far as I know, the grpc-web library doesn't support gRPC's usual message compression - the decompression would need to occur in Javascript, where it would be too slow to be useful. If you have your proxy server (usually Envoy) set up correctly, this should work automatically because browsers always set the "Accept-Encoding" request header. If you look at the response headers in your browser's network inspector, you should see "Content-Encoding" set to gzip or br. 

In your first attempt, you're correctly setting the grpc-accept-encoding header. I don't know the Java gRPC APIs, but it sounds like you're compressing the response correctly. Unfortunately, when the browser receives the response, it doesn't know how to decompress it and you're getting an error. The response can't decompress with standard gzip tools because it isn't valid gzip: following the gRPC protocol, each gzipped protobuf message is wrapped in five bytes of enveloping metadata. Because of the enveloping and the blob of gRPC-Web trailers at the end of the body, the response as a whole isn't valid gzip.

Your second attempt has the same problem. The correct response header is "Content-Encoding" (rather than "Content-Encryption"), but you end up with the same problem - gRPC's per-message compression doesn't produce the sort of compressed response that browsers expect.

Hope that helps,
Akshay
Reply all
Reply to author
Forward
0 new messages