HTTP/2 + connection pool settings in confighttp: what is the intended behavior?

[dsevr]

I’m trying to understand the intended contract around ForceAttemptHTTP2 in confighttp.ClientConfig.

As I read the code today:

• ForceAttemptHTTP2 defaults to true
• MaxConnsPerHost, MaxIdleConnsPerHost, and MaxIdleConns are documented as unsupported under HTTP/2
• These fields are still accepted in config but have no effect when HTTP/2 is used
• There’s no runtime warning or validation when these options are set together

Is my understanding of the current behavior correct, and is it intended to be doc-only, or should users expect some runtime signal when HTTP/2 is enabled and these options are set?

Code references

• Default HTTP/2 enabled: config/confighttp/client.go:L126–L134
• Documented incompatibility: config/confighttp/client.go:L106–L108
• No validation/warning: config/confighttp/client.go:L137–L144

Thanks.

[mg1986jp]

Yeah, your understanding looks correct to me. Go's net/http transport has a fundamental split: when HTTP/2 is negotiated, connection pooling is handled entirely by http2.Transport internally, and MaxConnsPerHost/MaxIdleConnsPerHost/MaxIdleConns on http.Transport get ignored. HTTP/2 multiplexes streams over a single connection per host, so the concept of a "pool of connections" doesn't really apply the same way.

In the collector's confighttp, ForceAttemptHTTP2 = true (the default) means the transport will try h2 via ALPN on TLS connections. If that succeeds, the pool settings become dead config. I don't think there's any validation or warning because this is inherited behavior from Go's standard library — net/http itself doesn't warn about it either.

Whether this should have a runtime signal is a fair question. The pragmatic answer: if you need to control connection count (rate limiting, resource caps), either set ForceAttemptHTTP2: false to force HTTP/1.1 where pool settings work, or accept that h2 gives you one connection per host with stream multiplexing. For most collector deployments, h2's single-connection model with multiplexing is probably fine, but if you're exporting to a backend that doesn't handle many concurrent streams well, forcing h1.1 + pool settings might actually perform better.

[Labeeb2339]

Your reading is still consistent with current main:

• ForceAttemptHTTP2 defaults to true and the ClientConfig comment explicitly says HTTP/2 does not support MaxConnsPerHost, MaxIdleConnsPerHost, or MaxIdleConns.
• ToClient copies those values onto http.Transport and sets ForceAttemptHTTP2; there is no validation or warning for the HTTP/2 plus pool-setting combination. The only warnings in this path are for deprecated keepalive field names.

Relevant current source: ClientConfig and ToClient.

If connection-count/idle-pool limits are requirements, set force_attempt_http2: false so the standard HTTP/1.1 transport semantics apply. If the actual requirement is detecting an idle or dead HTTP/2 connection, use http2_read_idle_timeout (and optionally http2_ping_timeout); current code wires those through golang.org/x/net/http2.ConfigureTransports to send HTTP/2 health-check PINGs. That is separate from TCP keepalive.

I would treat the missing runtime signal as an enhancement/documentation issue: the configuration is accepted intentionally, but a warning or validation error would prevent users from assuming the pool limits are effective.