Adding origin-side ALPN configuration.

[bneradt]

Adding the ability for ATS to specify the ALPN string it sends in the
TLS ClientHello handshake.

[maskit]

Thank you for making this PR, and adding the autest. I repeated my comments on #8963 so we can discuss here.

I think none of them is a blocker, but I'd like to hear opinions from others about the alpn_protocols setting. The documentation would need to be updated accordingly (it should tell which protocols are available anyway).

[maskit]

I'm not sure if users want to set "ALPN string".

The ALPN protocol IDs are inconsistent; The ID for HTTP/1.1 is "http/1.1" but not "h1.1" where ones for HTTP/2 and 3 are "h2" and "h3". I don't think these IDs are user friendly.

Even if we use those raw IDs, the doc should say what IDs are available. Obviously we can't set "spdy/1", although it's a registered valid ID. We shouldn't send "h3" on a regular TLS connection, and similarly we shouldn't send "h2" on a QUIC connection.

Also, the order of IDs is unclear if a user is unfamiliar with ALPN.

I don't have a good idea right now, but I think we need discussion about this setting at minimum. Changing this setting would be an incompatible change and we wouldn't be able to change it until 11.0 once we make 10.0 release with this setting.

[bneradt]

These are all really good points. I think I've addressed each of your thoughts:

1. I've updated the ALPN parsing logic to enforce that the user only passes expected protocols, currently http/1.1 and http/1.0. With HTTP/2 to origin we'll add h2. If any other protocol strings are passed, a WARNING is emitted and no ALPN extension is sent (the default behavior). This makes the configuration "fool-proof" for the user in that they can't break anything by configuring it, and a WARNING is emitted if something is wrong with their configured ALPN.
2. I expanded our documentation of this feature, pointing to the ALPN RFC and the official IANA list of registered ALPN protocol strings. I also explicitly documented the ALPN protocols ATS supports. (Again, we'll add h2 with the HTTP/2 to origin PR.)

Thank you for your thoughtful feedback on this, @maskit. It really improved this feature.

[maskit]

Thanks for updating the documentation. At minimum it works for me, but I can't tell if users want to read the external documents. The example configurations are nice. I guess most users would just see the examples, and copy a setting value from there. In that sense, whether name or ID is not really important, although I think using names (or aliases) requires less knowledge.

I'm not going to judge if the setting format is user friendly, but if I made a Web UI for a CDN service that uses ATS, it'd have a reorderable list for this setting and the items would have protocol names but not IDs. It wouldn't even tell it's a setting for ALPN.

And very strictly speaking, "," is a valid character for an ALPN protocol ID. I hope future protocol IDs (which we want to support) won't use it.

[maskit]

I'd like to hear how you (especially who are not too familiar with ALPN) want to configure which protocols to use/offer for origin connection.

Examples:

• h2,http/1.1 -- ALPN protocol IDs
• http2,http1 -- Aliases
• all -- Another alias to use all available protocols, and prioritize newer one

[maskit]

For server_ports, we no longer need to specify http/2 explicitly though, these protocol names (not IDs) are available.
https://docs.trafficserver.apache.org/admin-guide/configuration/session-protocol.en.html

[shinrich]

I'm confused why are we bringing this forward to 10-dev, but not just bringing in the Http2 to origin branch? Does this logic come from there?

[bneradt]

I'm confused why are we bringing this forward to 10-dev, but not just bringing in the Http2 to origin branch? Does this logic come from there?

Correct @shinrich. This comes from the HTTP/2 to origin PR (#8963) from which this PR was requested.

[maskit]

As for target branch, I'm fine with either 10-dev or master. I requested making this PR to have more eyes.

[maskit]

I can't tell whether users like the setting format, but it works for me at minimum.