client: set grpc-accept-encoding header based on outgoing compressor

[jiacai2050]

Apply this PR, the server will response with grpc-encoding whatever the client set. test via wireshark.

update #2786

[linux-foundation-easycla]

The committers are authorized under a signed CLA.

• ✅ Jiacai Liu (c4d223d)

[dfawley]

@jiacai2050 this is only a partial fix of #2786. It only addresses the client-side, and only on the outbound path (i.e. it does not respect the server's accept-encoding headers). Also it only presents the compression method used when sending the RPC. The client may support other codecs, however: everything registered with the encoding package.

Are you seeing problems when this header is not set (before this change)?

[jiacai2050]

It only addresses the client-side, and only on the outbound path (i.e. it does not respect the server's accept-encoding headers)

Yes, but this is the original logic. How can we get the accept-encoding sent by server's last response?

The client may support other codecs, however: everything registered with the encoding package.

Yes, but it seems there is no way to get all codecs since registeredCodecs is package-private.

Are you seeing problems when this header is not set (before this change)?

If this header isn't set, then the server will never send compressed response.

[dfawley]

Yes, but this is the original logic. How can we get the accept-encoding sent by server's last response?

This would have to be a new feature.

Yes, but it seems there is no way to get all codecs since registeredCodecs is package-private.

Correct. We could make this available to grpc's transport via the internal package to keep it unexported.

If this header isn't set, then the server will never send compressed response.

That makes sense - you mean for interop with other grpc languages, right? I think the grpc-go server is missing the implementation to not send compressed if the client doesn't set this header.

[jiacai2050]

you mean for interop with other grpc languages, right?

Yes, the server is built in rust.

After digging into how grpc-go client receive msg, I find it use compression set for outbound msg to decompress response, Is there anything I'm missing?

• https://github.com/grpc/grpc-go/blob/master/rpc_util.go#L659

d, size, err = decompress(compressor, d, maxReceiveMessageSize)
// should be
d, size, err = decompress(getCompressor(s.RecvCompress()), d, maxReceiveMessageSize)

[dfawley]

After digging into how grpc-go client receive msg, I find it use compression set for outbound msg to decompress response, Is there anything I'm missing?

I believe the code you found is fine. We set the decompressor based on the stream's header here:

grpc-go/stream.go

Lines 872 to 876 in 347a6b4

	if a.dc == nil || a.dc.Type() != ct {
	// No configured decompressor, or it does not match the incoming
	// message encoding; attempt to find a registered compressor that does.
	a.dc = nil
	a.decomp = encoding.GetCompressor(ct)

I will merge this PR as a short-term workaround for this issue, but we should not close #2786 yet as there are several more things needed.