Incompatibility between grpc 1.3.0 and grpc-java's OkHttp

[Eric Anderson]

If you have grpc-java OkHttp clients, avoid upgrading to 1.3.0 for any of the C-based languages.

We've been notified of an incompatibility. We will be working to fix grpc-java and figure out a fix for grpc/grpc to handle clients in-the-wild. We're still working on figuring things out; I wanted to send out a notification promptly.

[Eric Anderson]

Thank you everyone for waiting as we handled the incompatibility.

On further investigation, we believe few users in production would have experienced the incompatibility, as anyone with an L7 proxy (i.e., nghttpx) would avoid the direct incompatibility. The OkHttp transport is still broken and needs to be upgraded to avoid future incompatibilities. For example, in the future nghttpx could use a SETTINGS option unknown to OkHttp and trigger the same failure. However, most deployments serving Android would tend to be using a reverse proxy, and so side-step the problem.

gRPC Java v1.3.1 and v1.4.0 both include the client-side fix to this issue. If you are using the OkHttp transport, please make sure you are using v1.3.1 or higher. All earlier grpc-java versions included the bug.

Since clients can't always be updated quickly or reliably, and deployments may not be using a proxy, there is a server-side option to disable the bug-triggering behavior. If you need this workaround, please notify me via this list or directly via email, so that we can be aware.

Workaround for C++:

ServerBuilder b;

// ...

// Important line:

b.AddChannelArgument(GRPC_ARG_HTTP2_ENABLE_TRUE_BINARY, 0);

// ...

auto server = b.BuildAndStart();

Workaround for other C-based wrapped languages (everything but Go, Java, and C++):

Set add a server option with key "grpc.http2.true_binary" and value 0.