Relative links not allowed

[nwalters512]

This was originally called out in #51 (comment), but wasn't addressed before the issue was closed. I want to be able to create relative links in my output, but due to URLs without protocols being ignored (https://github.com/drudru/ansi_up/blob/master/ansi_up.ts#L691) this doesn't work. Is there a reason that relative URLs are explicitly disallowed here?

[drudru]

Ah. Yeah, I addressed it by sanitizing the output before putting it in the href.

As to why I didn't allow protocols, that is a good question. I have a few vague recollections, but it was mostly related to security.

I have a protocol whitelist in the code. Protocol restriction was discussed on the original gist where they were talking about adding this feature to the Ansi/Xterm etc. protocols.

So, lets discuss your case.
In my experience, I'm typically looking at logs on remote machines. If I'm looking through a log console, a relative URL doesn't make sense.
Also, in my particular use case, a relative URL only works sometimes. A lot of the URLs in the logs point to various machines in my cluster.
I think this is the general case for most production environments.

Can you elaborate as to why you want to use relative URLs?

[nwalters512]

I'm using this library to handle "logs" that are generated specifically for consumption by users of an application. Some of these logs come from tools like git, others are created programmatically by the application itself. I want to embed links to other pages in the application in these "logs". However, the part of the application generating these logs isn't aware (and frankly shouldn't be aware) of what host the application is being served from. Being able to use relative URLs would make this trivial.

[drudru]

As soon as those logs leave that machine, those URLs are broken.

I recommend forking your own copy and removing the protocol filter.

Best Regards

[nwalters512]

The logs don't leave any given machine, they're persisted in a database. The relative URLs embedded within would always be valid for whatever is serving the application.

It's unfortunate that the resolution to this is to maintain our own copy, as I still don't understand why relative URLs are disallowed. That they wouldn't work for your use case doesn't mean they can't work for mine where I can guarantee correct behavior. But if that's what's necessary, I'll do it. Thanks!