Validator.js: isURL() incorrectly claims http:// is valid url

[src-code]

validator.isURL('http://', { require_host: false }); // returns true

I understand that I could set require_host: true to get the right result, but then if the test string is a relative url (/example/foo.html), it won't validate. And I can't just || two executions of isURL() to cover both cases (as suggested for a similar issue), because it will lead to an incorrect result because http:// is flagged as valid in the above example:

var str = '/example/foo.html';
validator.isURL(str, { require_host: true }) || validator.isURL(str, { require_host: false }) // true

var str = 'http://';
validator.isURL(str, { require_host: true }) || validator.isURL(str, { require_host: false }) // true

It seems like validator should recognize that passing a protocol and nothing else cannot be a valid url, even if configured for not requiring a hostname.

[chriso]

This is fixed in an upcoming release.

[dsacramone]

Was this actually fixed, I am seeing this as a validURL, and I can't see how it is:

validator.isURL('http://www.te');

[src-code]

.te isn't a valid country code domain AFAIK, but if it were, www.te would
technically be a well-formed and valid URL. (eg www.com exists.)

[dsacramone]

validator.isURL('www.bro', { require_tld: true }) <-- WHY is this returning true. I clearly do NOT have a TLD here, yet, it is saying 'a-ok', why?

[chriso]

@dsacramone see #623, #428, #429, https://github.com/chriso/validator.js/issues/704#issuecomment-325167598.

www.bro is a syntactically-valid URL string, and bro is a syntactically-valid generic TLD. There is nothing special about the www subdomain, e.g. www.com is a valid hostname that resolves – there doesn't have to be anything between www and the TLD. Checking whether the generic TLD is registered with IANA is outside the scope of the library. The library doesn't, and will never, include the full, ever-changing list of generic TLDs – all it can do is check whether the string is valid. Checking whether the hostname resolves is also outside the scope of the library, although this is easy to do yourself if you're validating on the backend.