Autolinker incorrectly requires a full stop in URL and does not recognise links that start with http

[Matt-something]

Rocket.chat URL autolinker is not working correctly any more. We have many internal servers that are a single word such as

https://jira/ticket_number OR https:://regression/path/

Rocket.chat no longer recognises these as a URL. It only autolinks when a full stop . is in the URL.

Please fix the behaviour, such that autolinker creates a link for anything starting with standard nomenclature of http://, https://, ftp://, sftp://, i.e. a regex of a string beginning with (.*://) should always autolink.

This is on version 5.4.2

[hugocostadev]

The auto linker feature and the Legacy message template it's deprecated and they'll be removed in the next release (6.0).

Now we are validating if a link it's valid, and this type of link that you shared it's not valid because does not follow the proper URI pattern.

We'll discuss this internally if it's possible and desirable to highlight file paths (like yours).

[gregdavill]

While ICANN has banned the use of dotless domains on the internet, they are common on internal networks.
Since items that used to autolink are currently not autolinking. This is a regression.

Is there a concern that expanding the URI pattern to cover these form of links will erroneously flag not links? Because I'm seeing the exact opposite. All of these strings autolink, but none are actual links.

test_filename.py
main.cpp
example.so/dll

[hugocostadev]

Hi @gregdavill That's the exact concern that we have

If we let users to use dotless domains several normal texts can be confused by links, since each internal networks define its own structures....

About the links that you sent, I tested here and we started validating ICANN domains, the following links works properly:
The only one that it did not, .cpp because it is not a valid TLD

@matthias4217 and @gregdavill you can still create a link with dotless domain by using [Label](REF) structure.

[Matt-something]

@hugocostadev The point of those example files was to show that the autolinker is NOT working. It should not be autolinking Python files and library files. I am really disappointed with how poorly the Rocket.chat developers have implemented this feature.

[hugocostadev]

@hugocostadev The point of those example files was to show that the autolinker is NOT working. It should not be autolinking Python files and library files. I am really disappointed with how poorly the Rocket.chat developers have implemented this feature.

We are happy to hear your ideas on how to accomplish that without affecting valid links like notion.so for e.g, nowadays we support adding links without protocol, that's why in some cases it autolinks, if we rollback this feature will be tradeoffs

[AVsadov]

Hello!
I have the same problem. My domainless links are not autolinking anymore. How do I workaround?
I know about [Label](REF) structure, but is there another way to resolve it?

Unfortunately, only this issue prevents us from upgrading our chat infrastructure.

[herronelou]

How about allowing them as long as the protocol is present?

We've been using a lot of different protocols that are using the format a specified by https://datatracker.ietf.org/doc/html/rfc1738 and as of RocketChat 6, these do not get recognized as links anymore, impacting workflows where users are expected to freely being able to copy and paste these URLs around and click them in Rocket Chat.

For example: my-protocol://baked/202d6700 should get highlighted, but doesn't.

I don't see any argument where this can get mistaken with a "regular word".

[herronelou]

@hugocostadev can you suggest where in the code we could make a change to ensure that links with a full protocol are always detected as links? We deal with a high number of links with custom protocols that our users copy and paste on rocket chat, so updating to 6.0 is a big no-no until we find a solution for this.
Thanks.