Required C release for grpc-java 0.9?

[Ming Zhao]

I'm running the latest grpc-java as client against a server written in
C++, built with grpc commit 02128e9bbf92c3900f0927a724482b5b3ff7541f,
but I got the following error on the client side:

Oct 14, 2015 11:51:33 PM
io.grpc.internal.TransportSet$TransportListener transportReady
INFO: Transport 'io.grpc.netty.NettyClientTransport@648dcdec is ready
I1014 23:51:33.074008 17445 bank-server.cc:31] Making a deposit for the client
Exception in thread "main" io.grpc.StatusRuntimeException: INTERNAL:
Invalid content-type: null

Metadata({:status=[200], grpc-encoding=[identity],
grpc-accept-encoding=[deflate, gzip]})
DATA-----------------------------

Ilina�r@
Metadata({grpc-status=[0]})
at io.grpc.Status.asRuntimeException(Status.java:430)
at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:156)
at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:106)
at com.example.bank.BankGrpc$BankBlockingStub.deposit(BankGrpc.java:109)
at codelab.rpc.BankClient.makeDeposit(BankClient.java:39)
at codelab.rpc.BankClient.main(BankClient.java:46)

The client channel is created with:

channel = ManagedChannelBuilder.forAddress(host, port)
.usePlaintext(true)
.build();

[Eric Anderson]

Are you using grpc-java master? grpc-java 0.9 shouldn't have the issue, as the check was explicitly disabled:

https://github.com/grpc/grpc-java/blob/v0.9.0/core/src/main/java/io/grpc/internal/Http2ClientStream.java#L208

grpc-java master has the check and so requires grpc 0.11.1 or later, which had a fix backported.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAN7Vozy8X1cjPK-MYtevnT2RW0zCNHOm0RSQe946Vn4CnNeT_g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Ming Zhao(赵明)]

Thank you. I just realized I was on master and switching to v0.9.x
fixed my issue.
Is there any particular reason that check has to be added? I think
usually we shouldn't break wire protocol compatibility unless it's
really necessary.

[Eric Anderson]

Having a correct Content-Type has always been required. However, the first time Java enforced the requirement one implementation had an issue. Once that was fixed Java forgot to enforce it again until recently. And then that found a new bug. We decided to workaround the bug on our release, but not on master, because we really, really want Content-Type to be a useful signal.

Not having the Content-Type required makes error messages much less helpful when the remote is not gRPC. Instead of "Not a gRPC server" you get an error like "Frame header malformed: reserved bits not zero." Some proxies also add in a Content-Type of text/html if the content type is missing, so things can get messy without it.