Method on Authority to get the host without [] for IPv6 addresses

[gaynor-anthropic]

Right now Authority::host returns the hostname, dotted-ipv4-address, or []-surrounded-ipv6 address. However, for many use cases you don't want the [] for IPv6, they're part of the URI encoding, not the IP itself. Today's use case is transforming an HTTP Uri into a rustls-pki-type's ServerName, which doesn't accept the [] version.

[gaynor-anthropic]

Happy to send a PR for this if there's interest (and a decent name 😬)

[seanmonstar]

Yea, fair point. I've needed this before, and it currently lives split across 2 functions (what was I thinking?): https://github.com/hyperium/hyper-util/blob/e1c5a6c89bfaed11fb34bd483fe9ba616f403791/src/client/legacy/connect/http.rs#L536-L540 and https://github.com/hyperium/hyper-util/blob/e1c5a6c89bfaed11fb34bd483fe9ba616f403791/src/client/legacy/connect/dns.rs#L190-L204

It'd almost be too beautiful if there was just TryFrom<Authority> for SocketAddr, but dealing with the port is sometimes wanted, sometimes not...

[gaynor-anthropic]

That TryFrom would only handle IP hosts, right? I'm assuming it wouldn't do DNS resolution for hostnames.

Any suggestion for an appropriate method name on authority() for this?

[seanmonstar]

Yea it shouldn't do a DNS resolution. As for name or where it should live, could you consider the options, determine a recommendation, and why any alternatives are less favorable?

[gaynor-anthropic]

Sure. Three possible choices:

• bare_host() - It's the host() minus any adornment! This is probably the best purely because I don't like any of the other options, and it's fairly clear.
• hostname() - this name is what Go and Python use for the same concept, but it's not obvious from first principles why hostname() and host() are different.
• server_name() - this is what TLS connection would call this value (as seen in SNI), that said, it's got the same problem as hostname() in that it's not clear from first principles how it differs from host(). And also SNI in TLS doesn't actually allow IPs, so it imports the concept in a confusing way.

[seanmonstar]

I agree, what do these methods return that is different than host()? Oh, just that it would strip the brackets? That feels too tiny to provide, in my opinion...

[gaynor-anthropic]

Stripping the brackets is it :-)

The motivation is less that it's a lot of code (it's not! host.strip_prefix('[').and_then(|h| h.strip_suffix(']')).unwrap_or(host);), and more that it surfaces the concept in a way people are more likely to realize which one they need.

The failure mode here is really "someone uses host and then silently discovers their code is wrong on IPv6".

If that's too small to justify a new method, happy to wontfix.

[robjtede]

I agree that this is enough of a footgun since IPv6 is far enough outside the minds of "normal" application devs; I've run into this myself at work. If not a bare_host(), then I'd advise expanded documentation that shows upfront that the uri-host component can contain bracketed IPv6/IPvFuture addresses with a strip_{prefix,suffix}() snippet to copy-paste if what you're after is something like a host or x-forwarded-host header.

[seanmonstar]

To add another reference, here it is mentioned in RFC 9110 - IP-ID.

I link that either to inform a new method or a documentation update, whatever ends up being decided.