[o-nnerb]

makeTLSBootstrap always overwrites tlsConfig.applicationProtocols based on the configured httpVersion, even when the caller already set their own ALPN protocol list on the TLSConfiguration they passed in via HTTPClientConfiguration.tlsConfiguration. That list was silently discarded.

This only sets applicationProtocols from httpVersion when the caller left it empty, so a custom ALPN list set on the TLSConfiguration itself is respected.

[fabianfett]

Would you mind describing your use-case here?

[o-nnerb]

Thanks for asking, and sorry for the noise. I took another look from the RequestDL side, which is where this came from. RequestDL exposed applicationProtocols(_:) as a pass-through to TLSConfiguration, and that value was being discarded by AHC. That is what led me to open this PR.

I now think the right API for this is the existing HTTPClient.Configuration.httpVersion, not a custom ALPN list on the TLSConfiguration. AHC owns ALPN negotiation (matchALPNToHTTPVersion only accepts h2 and http/1.1), so respecting an arbitrary list would only let the two settings contradict each other. I've fixed this on the RequestDL side, so I'm closing this PR.

I'm leaving a note for anyone who hits the same surprise (a value set on TLSConfiguration.applicationProtocols having no effect): to control the protocol, use httpVersion:

• .http1Only forces HTTP/1.1
• .automatic (the default) uses HTTP/2 when the server supports it over HTTPS, and HTTP/1.1 otherwise

There's currently no way to force HTTP/2-only, and AHC doesn't support HTTP/3.