Prepend external URLs with scheme

[myfluxi]

If URL values are stored normalized, scheme might be missing. This usually leads to external links being prepended with the server's base URL. In such cases prepend with the https scheme instead.

[myfluxi]

Or should this be handled in UrlConfigurator?

[javiereguiluz]

Maybe I'm missing something, but I don't fully understand this proposal.

What if someone uses http://example.com ? The result would be https://http://example.com I'd say we shouldn't try to fix the values passed by the developer to the URL fields, because there are many types of valid URLs, so we can't fix all possible variants and doing so could be wrong in some cases.

If I missed something or you have more information, please add a comment and we can reopen this. Thanks!

[myfluxi]

Thanks for looking at this change.

If the field is of type UrlField, there are three options: a) the value starts with http:// b) the value starts with https:// c) the value starts with neither but should be considered a valid FQDN (because why use this type at all then? the value itself would be bad to begin with)

The regex handles all the these possible values. Hope this helps to clear things up.

See: https://regex101.com/r/7eHy12/1

[michaelKaefer]

@myfluxi I still agree with @javiereguiluz and think it should be closed.

If the value is foo (which is a valid value) then we cannot assume that every developer always wants to link to https://foo and not to http://foo and not to file://foo and not to https://currently-visited-domain.com/foo (= relative URL, which seems also possible: https://stackoverflow.com/questions/8951423/html-links-without-http-protocol).

Also if the value URL has another valid scheme like file://foo then it would become https://file://foo.

In my opinion we should not guess the scheme here but rely on the browser default (for example described in https://stackoverflow.com/questions/8951423/html-links-without-http-protocol).

[myfluxi]

I totally see your point here, @michaelKaefer, thanks for pointing this out.

Then again, taking in account what the default user expects and how the normal distribution of URI types appears to be (it's 98% https these days, http is very rare and file is quite an esoteric case in real life web applications).

How about the following where we consider all the scheme types, also honour the server's base scheme and only prepend with //?

{(^(https?|file):)?//}' ? field.value : '//' ~ field.value }}

See: https://regex101.com/r/vzyZaB/1

I'm very fine if you close this PR from a maintainer's point of view; I'm coming here as a user :)

[javiereguiluz]

@myfluxi thanks for the additional details ... but after thinking about this again, I've decided to close without merging.

I don't think your proposal is entirely wrong ... but given that URLs/URIs can use so many different formats, including weird edge cases like the one Michael mentioned, this could probably break some apps.

Let's put the responsibility of having correct data to the developers of the apps (they can fix things in setters/getters or when creating/persisting data). The only exception is when the HTML fields mandates some specific format ... in those case we can try to fix common issues or throw exceptions if not possible.

Thanks!