enable HTTP/2 support in transport connecting to api?
TLDR: We currently are running on HTTP/1.1 when connecting to gitlab's API and it's probably fine to keep that as is. The behaviour is more consistent, and that gives us less surprises in production.
This is one of the changes that was extracted from !274 (merged).
Golang's DefaultTransport
has HTTP/2 (henceforth "h2") support enabled by default.
However, gitlab-pages uses a custom transport, and is not configured for h2.
From the Transport
documentation:
// ForceAttemptHTTP2 controls whether HTTP/2 is enabled when a non-zero
// Dial, DialTLS, or DialContext func or TLSClientConfig is provided.
// By default, use of any those fields conservatively disables HTTP/2.
// To use a custom dialer or TLS config and still attempt HTTP/2
// upgrades, set this to true.
ForceAttemptHTTP2 bool
Since we are overriding DialTLS
, we do not get h2 support by default.
We can change that behaviour by setting ForceAttemptHTTP2
to true
.
Note: For gitlab.com, we currently are getting h2 from Cloudflare. If we decide to switch to an internal load balancer (e.g. gitlab#215321 (closed)), we will fall back to the good old classic h1.
For this reason I wanted to open this as an issue first, so that we can discuss if it even makes sense. And so that the decision is at least documented.
From an operational perspective, it may be safer to keep it as-is. We will get more consistent behaviour regardless of whether we go through Cloudflare or not. The benefits of h2 are less pronounced for API clients. We would get some nice bits like header compression, and perhaps others can chime in with ideas.
I'm inclined to keep using h1 for now. What do others think?
cc @jarv @vshushlin