website key without "http" links to the OSM website

[maro-21]

When browsing a node or way, with the key "website" if the URL doesn't contain "http", but just "www", then the link directs to https://www.openstreetmap.org/node/555555/www.example.com
From what I remember, I think it used to not be like that and the links worked correctly.

[tomhughes]

This is why we shouldn't try and linkify things - there's simply no way we can ever guess correctly what people mean when they can enter any old nonsense.

In this case we interpret whatever is entered there as a link, and a link with no host will therefore be interpreted as relative to the current page. I very much doubt we have ever done anything else but you're welcome to provide evidence that we used to do something else.

Probably we should just refuse to link anything which doesn't look like an absolute URL as there's no way to know what somebody might mean for other things.

[pablobm]

I think it's worth considering the user experience. Many tools that we use every day allow us to enter schema-less URLs. It makes sense, because writing https:// every time is a chore.

I think it's worth asking how other apps do it. I suspect that they may use something like https://publicsuffix.org for a heuristic. We could experiment with that (or other options) to see how they cope with existing entries in the DB, etc.

Incidentally, I see there's a Ruby gem for those suffixes: https://github.com/weppos/publicsuffix-ruby.

[1ec5]

The website=* key has long been documented as requiring a protocol for the sake of data consumers, and most data consumers expect it. Validators like Osmose already warn about malformed URLs. iD used to but regressed: openstreetmap/iD#11436. Most users probably copy-paste URLs rather than typing them in manually, but if users find it tedious, the validator warning could come with a button to automatically add a protocol. Arguably, leaving the URL unlinked would be valuable feedback to the mapper that something is wrong.

In principle, website=* should be just a single URL, so we don’t have to guess the boundaries of a URL within running text, which can be tricky (think parentheses). However, there are about 2,200 occurrences of semicolon-delimited value lists, which clashes with about 700 occurrences of URLs that might legitimately contain semicolons under RFC 1738.

Incidentally, we’re optimistically linkifying URLs inside other freeform text keys like source=*. This works when there’s a full URL, and in the very common case that the source is merely a domain name, it seems to be working too. So we do still have the capability of forming a correct link out of a partial URL.

#6197 integrated tag2link, which has a rule for website=* specifically. As part of the integration, we skip tag2link in favor of the preexisting linkifier if it starts with HTTP or HTTPS. I’m guessing the bogus links are because we fall through to tag2link in the case of a malformed URL.

openstreetmap-website/app/helpers/browse_tags_helper.rb

Lines 139 to 140 in 8bd509b

	# skip if it's a full URL
	return nil if %r{^https?://}.match?(value)

[pablobm]

Would it be possible (and make sense) to show a warning icon to raise that there's an issue, while at the same time render the link, automatically prefixed with https:// (or http://)? (I don't know all the possibilities when rendering the tags table).

Getting iD to validate and offer affordances sounds good. However I am concerned about historical values, plus future ones added by clients that don't validate. If I'm doing this right, there are about 35k+ occurrences of values starting with www. at the moment (and 56k+ occurrences just missing a protocol).

[maro-21]

Probably we should just refuse to link anything which doesn't look like an absolute URL

This would be better than the current state because when someone sees no clickable link after "website", they could click Edit and correct it.

In cases like this it's even better not to link. Becase the correct link
https://www.booking.com/hotel/it/giuseppe-amp-giuseppe.html?aid=376372;label=it-5Srxg0e1twJI_ryrey2UnQS267778030993:pl:ta:p1:p22.389.000:ac:ap1t1:neg:fi:tiaud-294889295893:kwd-65526620:lp20533:li:dec:dm;sid=0c7be8913f46cbac0366e17b4cc1c397;frindrecv=1 is changed to 3 links:

• https://www.booking.com/hotel/it/giuseppe-amp-giuseppe.html?aid=376372
• https://www.openstreetmap.org/node/label=it-5Srxg0e1twJI_ryrey2UnQS267778030993:pl:ta:p1:p22.389.000:ac:ap1t1:neg:fi:tiaud-294889295893:kwd-65526620:lp20533:li:dec:dm
• https://www.openstreetmap.org/node/sid=0c7be8913f46cbac0366e17b4cc1c397

Incidentally, we’re optimistically linkifying URLs inside other freeform text keys like source=*. This works when there’s a full URL, and in the very common case that the source is merely a domain name, it seems to be working too.

Exactly. I knew I saw links without http that worked. Why linking works with [source] but doesn't work with [website]??

[pablobm]

Regarding that example link to booking.com, that's partially a different problem:

• It's a different problem in that the user entered a URL with semicolons, which technically they shouldn't have (but I can't blame them).
• It's the same problem in that the incorrectly-splitted strings shouldn't be rendered as links.

My impression is that multiple values (semicolon-separated) should be rendered differently. Perhaps in different lines, hopefully not all in a single line as that's not visually obvious. Then each separate link could get whichever treatment we see appropriate: not render as a link, show a warning sign, etc.

Perhaps editors like iD should offer to enter multiple values in separate form fields, then join them with semicolons behind the scenes. This way the editor could automatically escape the semicolons to %3B, avoiding this problem. Having said that, in this case the changeset was produced with Level0, so that wouldn't have helped.

Looked into why website= and source= are treated differently. At a technical level, the website code delegates some decisions here to https://github.com/JOSM/tag2link. This in turn has:

• A special case for website (code), telling it to render the value exactly as given. Therefore www.example.com remains unchanged, without being automatically prefixed with a scheme.
• No mention of source. The default behaviour here is to apply a smart linkification using https://github.com/vmg/rinku. (Code rabbit hole starts at browse_tags_helper.rb)
  As for whether there's a reason for this, I don't know. I'm guessing it's a historic accident, and both should be made to render the same way.