sahvx655-wq opened a new pull request, #405: URL: https://github.com/apache/commons-validator/pull/405
While checking how UrlValidator handles IPv6 literals I noticed it accepts `http://[::FFFF:129.144.52.38]/` (the case covered by `testValidator452`) but rejects the same address in the standard lower-case mapped form `http://[::ffff:129.144.52.38]/`, and likewise rejects the IPv4-compatible `::1.2.3.4` and embedded `2001:db8::1.2.3.4` notations. The cause is `IPV6_REGEX` used by `isValidAuthority`: it only special-cases the literal upper-case `::FFFF:` prefix and otherwise matches `[0-9a-fA-F:]+`, which has no `.`, so any bracketed host with an embedded IPv4 part fails the authority match before `InetAddressValidator.isValidInet6Address` is ever consulted. That validator already accepts all of these forms, so the URL path and a direct address check disagree. The bracketed group is captured and then handed to `isValidInet6Address`, so the regex only needs to delimit the candidate rather than judge it; I widened it to `[0-9a-fA-F:.]+` and left the real decision to the address validator. Keeping the judgement in one place stops the two paths drifting apart again, and malformed hosts (bad octet, stray `::`, over-long group) are still rejected because the address validator rejects them. Left unfixed, code using UrlValidator as an allow gate silently turns away legitimate IPv4-mapped IPv6 URLs. - [x] Read the [contribution guidelines](CONTRIBUTING.md) for this project. - [ ] Read the [ASF Generative Tooling Guidance](https://www.apache.org/legal/generative-tooling.html) if you use Artificial Intelligence (AI). - [ ] I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute? - [x] Run a successful build using the default [Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command line by itself. - [x] Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice. - [x] Write a pull request description that is detailed enough to understand what the pull request does, how, and why. - [x] Each commit in the pull request should have a meaningful subject line and body. Note that a maintainer may squash commits during the merge process. -- 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]
