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

[Danil Vilnikov]

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]

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]

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