[
https://issues.apache.org/jira/browse/VALIDATOR-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17152362#comment-17152362
]
Ivan Larionov commented on VALIDATOR-429:
-----------------------------------------
Should be fixed in VALIDATOR-467.
> UrlValidator - path is invalid due to using java.net.URI for validation
> (regression)
> ------------------------------------------------------------------------------------
>
> Key: VALIDATOR-429
> URL: https://issues.apache.org/jira/browse/VALIDATOR-429
> Project: Commons Validator
> Issue Type: Bug
> Components: Routines
> Affects Versions: 1.6
> Reporter: limpygnome
> Priority: Major
> Labels: easyfix
>
> h1. Summary
> We've been hit by a bug in a real world application after upgrading 1.4.1 to
> 1.6, where previously valid URLs are no longer valid, which looks to be due
> to using java.net.URI for validating the path of a URL.
> h1. Steps to Reproduce
> Our application went to validate URLs similar to the following:
> * http://example.com//_test
> This is no longer valid in 1.6.1, but the following cases are:
> * http://example.com//test
> * http://example.com/_test
> h1. Impact
> It seems paths in UrlValidator are being parsed/validated as host-names, per
> java.net.URI's validation.
> h1. Technical
> It looks like this may have been introduced by the following change:
> https://github.com/apache/commons-validator/commit/03bf0d33143ebd13e4f389cd4ecac8aec17c2057
> Specifically due to now using java.net.URI to validate a path. The usage is
> as follows in org.apache.commons.validator.routines.UrlValidator:
> {code}
> URI uri = new URI(null,null,path,null);
> {code}
> It looks like URI is trying to parse the path as a hostname when the schema
> and hostname are not specified.
> Example to reproduce:
> {code}
> new URI(null, null, "//_test", null); // throws URISyntaxException
> {code}
> Same example with other parts, no longer throwing exception:
> {code}
> new URI(null, "test", "//_test", null);
> {code}
> Even though java.net.URI states string components can be null, it seems the
> URL built internally, which is validated, is slightly different. So when
> specifying a hostname with URI, internally it constructs:
> * //test//_test
> Using no hostname, in the same way as UrlValidator, the following is
> constructed and validated internally:
> * //_test
> Therefore it looks like there's either a bug in java.net.URI, or its usage is
> not correctly documented.
> h1. Fix
> A potential fix is to change
> org.apache.commons.validator.routines.UrlValidator to pass an empty string in
> the hostname. Internally, in java.net.URI, this produces:
> * ////_test
> Thus the hostname is empty, which is considered empty, and the correct path
> is validated.
> Would this fix be appropriate, or considered too fragile?
> Alternatively the fix could be to extract similar logic to java.net.URI, to
> validate the path, which appears to be just checking the characters are valid
> and between a certain range. This logic can be seen in
> java.net.URI.parseHierarchical, which calls upon checkChars.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
