Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Client-side h2c (insecure HTTP/1.1-to-h2) upgrade does not work #4518
There seems to be quite a bit of machinery in place to make this work, but currently the client does not start sending the request after performing the TCP handshake. A possible fix for this has been previously proposed in https://github.com/grpc/grpc-java/pull/3529/files#diff-e805c3ddf2a8c848220b85c467f5f408R379 (and when I tried this locally it did appear to help), but the code has evolved since.
Our use case for this feature is that while in production you'd use TLS and ALPN to serve both HTTP/1.1 and h2 requests on the same port, during development it can be convenient to run without TLS.
What version of gRPC are you using?
Checked on 1.11.0, 1.12.0 and master.
What did you expect to see?
I expected the grpc-java Netty client to successfully connect to a h2c endpoint when configured with
I'm not sure it actually did work, despite the correctly named symbols being present. The
I can't see any strong reason to disable it, but I don't think it was supported.
I looked into it further: the server should send the response to the request with the
However, since that stream isn't started at the grpc-java side, when the first header frame comes in at
I poked around a bit but didn't find an elegant way to pre-initialize stream
@raboof, hmmm... I think netty starts with stream id 3 independent of whether Upgrade is used. So it may be possible to just ignore the header response for stream 1.
It'd probably be good to add a validation check that we aren't using