sahvx655-wq opened a new pull request, #421: URL: https://github.com/apache/commons-validator/pull/421
UrlValidator.isValidAuthority rejects an authority that carries userinfo before a bracketed IPv6 host, so `http://user@[::1]/` and `http://user:pass@[2001:db8::1]:8080/` come back invalid. The same host without the credentials (`http://[::1]/`) validates, and userinfo before a hostname (`http://[email protected]/`) validates, so the two accepted shapes ought to combine; `java.net.URI` parses `user@[::1]` without complaint and RFC 3986 ยง3.2 places the optional userinfo before a host that may itself be a bracketed IPv6 literal. Tracing AUTHORITY_PATTERN against `user@[::1]` showed the host group coming back empty with `[::1]` captured in the trailing "extra" group, which is what fails the match. The cause is that AUTHORITY_REGEX only offered the userinfo prefix inside the reg-name/IPv4 alternative, never before the `\[(IPv6)\]` alternative, so the userinfo branch consumed `user@` and then matched an empty host. I lifted the userinfo group out of the host alternation so it precedes either host form. The capture-group numbers stay put because USERINFO_FIELD_REGEX contains no capturing group, so the IPv6, host, port and extra groups isValidAuthority reads still line up, and the existing IPv6 content and port-range checks keep running through the userinfo path. Left as-is, anything relying on this to admit authenticated IPv6 URLs quietly treats valid addresses as invalid. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
