Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

This is a case in which we might have a hard time finding the expertise to figure out what to do here. We have tests that expect both to be able to pass domains with underscores (seen in legacy Amazon S3 buckets, I'm reading) and to be able to pass non-ASCII characters (typically converted to Punycode automatically by browsers). We've also seen (non-HostSpecifier) code that tests with non-ASCII digits.

Thanks, that makes sense.

My intent was not to change the broader behavior of InternetDomainName or InetAddresses. I was focusing on HostSpecifier because its class-level contract says the value is suitable for use in a URI, while these inputs can produce a parser differential with java.net.URI#getHost().

I agree that rejecting all non-ASCII domain names may be too broad if callers expect browser-like IDN handling. A narrower option could be to canonicalize IDNs through IDN.toASCII so HostSpecifier still returns a URI-safe host form instead of rejecting them outright.

The underscore case seems harder because java.net.URI does not treat foo_bar.com as a host at all, so preserving underscore compatibility conflicts with the current HostSpecifier URI-suitability wording. If preserving legacy underscore support is preferred, then maybe the safer change is documentation/API guidance rather than changing HostSpecifier.isValid behavior.

Which direction would you prefer for this PR: a narrower IDN canonicalization patch, documentation clarification, or keeping the stricter URI-host validation?