On 4/28/19 8:26 AM, Lukas Fleischer wrote:
On Sat, 27 Apr 2019 at 23:49:11, Eli Schwartz wrote:
Ah... yeah, that is a pretty good point. I'd probably want to display that as straight up plaintext.
It definitely should not be appended to the cgit url if it is a valid schema, though. And regarding not making a link at all (e.g. for the common git:// protocol), how would that play with renamed sources like "$pkgname::git://example.com/project-something"?
What's the problem with that?
We always remove the "$pkgname::" prefix. And then, this source would be shown as "git://example.com/project-something" without linking to anything.
We could do as you say. But currently, we are setting the link text to "$pkgname", which I guess would not have an analogue for text-only sources without an href. It would be a touch inconsistent.
I wish php had a schema validator that wasn't broken... python's urlparse cleverly handles all this nonsense, and you can just refuse to print urls with ParseResult(scheme='javascript',...). Maybe we should do string comparisons to reject javascript schemes? Is there anything else which matters in this context?
We could do that. But why blacklist instead of whitelist for such a minor feature? I suggest to convert local links to cgit URLs, convert HTTP/HTTPs/FTP to absolute links, and display everything else in plain text.
I don't know. :D It seems like it would be reasonable to go either way: fix some current urls, or drop support for all the irregular ones. Do we have any statistics on whether people actually use different urls for anything? I mean, I suppose in theory one could have a custom scheme handler for git:// which would open in some GUI shell for git repositories. But that be sort of reaching for an excuse. -- Eli Schwartz Bug Wrangler and Trusted User