no-default-alpn

[zirngibl]

Hi,

According to RFC9460 HTTPS resource records indicate http1.1 by default. The ALPN value does not have to be listed explicitly.
In contrast, the no-default-alpn parameter would remove http1.1 from the list of supported ALPNs. should this be considered here? [1]

[1] https://www.rfc-editor.org/rfc/rfc9460.html#section-9

https://github.com/mxinden/happy-eyeballs/blob/8277ee298fa2cbf5d5eae42d42e79f354356f0a1/src/lib.rs#L1096

[mxinden]

A DNS HTTPS record result would be passed to the state machine via the ServiceInfo structure:

/// Service information from HTTPS records
#[derive(Clone, PartialEq)]
pub struct ServiceInfo {
    pub priority: u16,
    pub target_name: TargetName,
    pub alpn_protocols: HashSet<Protocol>,
    pub ech_config: Option<Vec<u8>>,
    pub ipv4_hints: Vec<Ipv4Addr>,
    pub ipv6_hints: Vec<Ipv6Addr>,
}

The ServiceInfo structure contains a set of Protocol.

#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash, PartialOrd, Ord)]
pub enum Protocol {
    H3,
    H2,
    H1,
}

I find the no-default-alpn mechanism in DNS HTTPS records unnecessarily complex. (I might be missing a key insight.) Instead of duplicating this complexity in this implementation, I expect the user to handle the complexity as such:

• A DNS HTTPS record with alpn = "h2, h3" would be passed to this library as alpn_protocols: [H1, H2, H3].
• A DNS HTTPS record with alpn = "" would be passed to this library as alpn_protocols: [H1].
• A DNS HTTPS record with alpn = "h3", no-default-alpn would be passed to this library as alpn_protocols: [H3].

@zirngibl does this make sense? Am I missing something?

[zirngibl]

I agree that this is unnecessarily complex. To me it feels like the example in #10 would have wanted the no-default-alpn key to actually map different protocols to different endpoints but missed it.

To my understanding of the RFC, your examples seem correct. Handling this complexity by the user/the library parsing HTTPS records seems reasonable.