On 2021-10-12 at 20:42:01, Jeff King wrote: > On Tue, Oct 12, 2021 at 10:47:01AM -0700, Junio C Hamano wrote: > > > "Alex Waite" writes: > > > > > This works for all tested subdomains /except/ for those which contain an > > > underscore. > > > > > > authenticates without prompting: > > > git clone https://testA.example.com > > > git clone https://test-b.example.com > > > > > > prompts for authentication: > > > git clone https://test_c.example.com > > > > Hmph, given that hostnames cannot have '_' (cf. RFC1123 2.1 "Host > > Names and Numbers", for example), the third URL seems invalid. Is > > this even a bug? > > That may be so for hostnames in general, but URLs seem to allow it. RFC > 3986 says: > > host = IP-literal / IPv4address / reg-name > reg-name = *( unreserved / pct-encoded / sub-delims ) > unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" That's what the schema says. The text says this: A host identified by a registered name is a sequence of characters usually intended for lookup within a locally defined host or service name registry, though the URI's scheme-specific semantics may require that a specific registry (or fixed name table) be used instead. The most common name registry mechanism is the Domain Name System (DNS). A registered name intended for lookup in the DNS uses the syntax defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. Those RFCs disallow the underscore. If we plan to allow names that are not registered in the DNS, we should clearly specify what those are and document how they work in conjunction with libcurl (which presumably does a DNS lookup on them). It's my guess that there are going to be system resolvers which are not going to accept this syntax in getaddrinfo and as a result, we're going to have various breakage across systems if we try to accept this. I'm happy to put in a change to reject these hostnames altogether, but I won't get to it before Friday. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA