HTTP/2 Support

[molikuner]

Is your feature request related to a problem? Please describe.
We're currently running skipper as our API Gateway for external and internal traffic. There are upcoming internal requirements to support gRPC traffic.

Describe the solution you would like
Skipper should be able to receive and make unencrypted HTTP/2 requests and responses (including Trailers), such that gRPC traffic can flow through it.

Describe alternatives you've considered (optional)

• Route gRPC traffic outside of Skipper (and optionally replace Skipper entirely)
• Do not support gRPC traffic

Additional context (optional)
At the moment we do not have any strict requirements to inspect the gRPC traffic. For now we would simply like to route traffic based on Header and potentially Path predicates to different backends.

Would you like to work on it?
Yes, but likely we would need some support to answer some open questions (see below).

Related Issues
#1253
#906
#4085

Identified issues so far

• Skipper silently drops Trailers from responses
• Skipper doesn't accept h2c requests
• Skipper doesn't create h2c & h2 requests

Open questions

• Would you be open to accepting contributions in this direction?
• Should there be a dedicated configuration option to enable HTTP/2 support (incoming and/or outgoing)?
• Should there be a dedicated configuration option to enable Trailers forwarding?
• explore NewClientConn from go stdlib #4085 mentions NewClientConn. Would contributions to enable HTTP/2 only be accepted if they're migrating to NewClientConn, or would it be okay to continue to use the existing Transport infrastructure for now?
• Should the outgoing connections start to using the AppProtocol, e.g. values like kubernetes.io/h2c? How would this relate to the zalando.org/skipper-backend-protocol annotation?

[szuecs]

In general it would be a nice contribution. It's really part of the core and likely we need to build it on our own. I waited for the official Go support without x/net.
After my vacation I wanted to focus on this anyways so likely you need to wait a bit.
There are internal needs that also want to have grpc support.
What I'm not sure about is h2c support. I always thought it is a good idea but I think the Go maintainers have a different idea. Therefore I checked SPIFFE/SPIRE and it would enable plain h2. When I am done I will document it so it's easy to build the system, but of course it is not a trivial setup.

Your issue will have to be done by multiple PRs: net.Client, proxy, server handler and kubernetes.

I hope it matches your expectations.

[molikuner]

Thanks @szuecs for getting back to me so quickly!

Isn't it officially supported by Go now? That's net/http not the x/net/http2 package.

What I'm not sure about is h2c support.

There is this UnencryptedHTTP2 in the Server.Protocols and Transport.Protocols, that allows HTTP/2 with prior knowledge. While it doesn't handle the HTTP/1.1 Upgrade, making and receiving cleartext HTTP/2 requests is possible, if explicitly configured.

I always thought it is a good idea but I think the Go maintainers have a different idea.

Where did you find this? Or did you just mean the HTTP/1.1 Upgrade support?

I checked SPIFFE/SPIRE and it would enable plain h2. When I am done I will document it so it's easy to build the system, but of course it is not a trivial setup.

While it sounds reasonable, I don't think it would be easy for us to implement fully encrypted traffic at the moment. I think rather than implementing SPIRE we would likely migrate to some other proxy for gRPC then.

[szuecs]

If you don't need x/net/http then ho ahead and create a PR.
Let's see if it's possible.

I just followed a couple of go issues over the years and my perception was different from your message.