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
signature.asc
Description: OpenPGP digital signature
