On Sun, 15 Aug 2004 23:23:07 -0400, Tim Reilly
<[EMAIL PROTECTED]> wrote:
> Thanks Martin!
> Then it appears I was using the is validScheme etc incorrectly and as well a
> bug. I've open a bugzilla issue for the optional port and path issues.
>
> I have started a patch for this.
>
> Starting with the unit test:
> The patch seems easy enough. In the arrays of test parts I'm adding empty
> strings such as
>
> - TestPair[] testPath = {new TestPair("/test1", true),
> + TestPair[] testPath = {new TestPair("", true),
> + new TestPair("/test1", true),
Actually, if you look a half dozen lines further down, you'll see that
the empty string is already there, but with a 'false' validity. So
someone seemed to think that an empty path should not be valid. The
RFC says it should be, though.
> Question 1)
> Which should be valid according to the rfc:
> http://www.google.com
> or
> http://wwww.google.com/
> or both perhaps?
> I'll adjust the test data accordingly.
Both. The RFC specifically allows for an empty path (the former) and a
path of "/" is a perfectly valid path (the latter).
> Question 2)
> On line 206 of UrlTest I'm confused by
> new TestPair("", true)};
> seems to be constructing a case where scheme may be EMPTY_STRING as valid.
> I'd assumed scheme is always required of a url, but admit I've not read the
> rfc you mentioned.
The RFC does in fact state that the scheme is *not* optional. I'm
guessing that this test might be trying to test relative URLs - but
that is just a guess, since I haven't been involved with this class up
to now.
> Question 3)
> Changing the UrlValidator should be a matter of getting the regular
> expression correct I believe(?) for the empty path parts.
I'm not sure if it's that easy or not. The convoluted (IMHO) nature of
the tests makes it a bit difficult to figure out just what is being
tested and how. Specifically, it's hard to see what URLs are being
tested, and so hard to know whether or not the tests are correct.
> One thought I had on port validation was to attempt to construct a
> java.net.URL and do something like
>
> if (u.getPort() < 0 && u.getDefaultPort() < 0) {
> return false;
> }
> which I think would mean the protocol handler for the scheme has a known
> default port. Does this sound like a good approach? or is there a case where
> someone has a protocol handler with default port that java.net.URL wouldn't
> know about? Or a case where java.net.URL is going to throw
> MalFormedUrlException where UrlValidator.isValid would otherwise return
> true?
I'm going to leave this to someone who knows more about this code than I do...
> NP on the 1.1.4 status for me. If getting patches in can get it to 1.1.3
> that'd be good too, either way.
We've already voted 1.1.3 to GA, so I'm reluctant to open it up again
for more changes. Theoretically, a 1.1.4 can happen before too long in
any case.
--
Martin Cooper
> Thanks,
> -TR
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
