URI.withinString finds invalid hostnames

[xPaw]

This appears to be a new issue in one of the latest versions.

We have code like this:

	URI.withinString(text, function(url, start, end) {
		// Extract the scheme of the URL detected, if there is one
		const parsedScheme = URI(url).scheme().toLowerCase();
	});

and now it throws Hostname "-oProxyCommand=whois" contains characters other than [A-Z0-9.-:_] on URI(url) line, which did not happen before.

[rodneyrehm]

Hostnames are validated since v1.18.11. What is the actual input you're dealing with?

[xPaw]

That would be a string like you mean ssh://-oProxyCommand=whois. I would expect withinString to not find it if URI is going to throw on same url.

[rodneyrehm]

So you'd like to parse the matched string ("slice") before handing it to the callback? Do you want to send a PR for that?

[xPaw]

We are already parsing the matched string to fix some url matching with known schemas, and the recent validation change basically breaks this. I am not that interested in figuring out how I would validate it to send a PR as I don't see a tryParse mechanism somewhere. Easiest fix I can do is just wrap URI(url) in a try/catch in our code, but that seems to defeat the purposes of using withinString in the first place.

[rodneyrehm]

We are already parsing the matched string to fix some url matching with known schemas

which are?

Easiest fix I can do is just wrap URI(url) in a try/catch in our code, but that seems to defeat the purposes of using withinString in the first place.

a) that's basically what I would have done
b) not sure it does since the callback is not invoked for obviously invalid input

[xPaw]

which are?

https://github.com/thelounge/lounge/blob/28e32dc5585d2401dc8431f6069a413177acb21d/client/js/libs/handlebars/ircmessageparser/findLinks.js#L25

not sure it does since the callback is not invoked for obviously invalid input

except it does and that's the entire problem here. It's finding an url with invalid hostname which fails in URI function.

[rodneyrehm]

As the hostname validation caused some kerfuffle I've decided to make this feature opt-in, thereby returning to the previous default behavior of v1.18.10. As of v1.19.0 you can activate hostname validation globally by setting URI.preventInvalidHostname = true, or on an instance by calling .preventInvalidHostname(true).

I'm sorry for the confusion, inconvenience caused by the original change and the delayed rectification.

[astorije]

Thank you @rodneyrehm! ❤️