4 ms·

I encountered another pitfall when using `new URL` to check if a text contains urls. It accepts strings like ”example:”, “next:", etc. as valid urls because it

by ngruhn 2y ago

I encountered another pitfall when using `new URL` to check if a text contains urls. It accepts strings like ”example:”, “next:", etc. as valid urls because it interprets the string before the colon as a custom protocol. This is a real edge case in the spec, because with common protocols, just "http:", "https:" is not accepted as a valid url.

jeroenhd 2y ago
It's correct, though. The URI scheme for HTTPS may always include a domain name, but my-app: is just as valid a URL as anything else. A protocol where everything is optional and the default opens a screen with all fields empty is valid, though unlikely. For instance, an empty mailto: will reliably launch an email client, even if no address is specified. I think it's the second most used protocol in web links, after HTTP(S). If you want to to URL parsing by brute forcing URL constructors, you probably don't want application URLs in the first place. You should probably start with https:// https:// and http:// http://, or make use of the weird double slash HTTP introduced into the URL by matching on :// instead.
- mstade 2y ago
  Well, ackchyually... If you want to get real anal about it the API should probably called URI instead of URL. The latter should describe where to access the resource, not just how to identify it, and to truly be able to do that you must also know something about the scheme. At the very least you must know whether the scheme imposes further restrictions on the individual parts of the URI, otherwise you can only determine whether it's a valid URI but not truly say whether it's a valid URL. In practice no one really cares much about the distinction between identifiers and locators, and arguably it was a mistake to try and make that distinction in the spec. But it is in there after all and I find it a bit ironic that the authors of the JS spec chose to ignore it. There's probably good reason for it, but still. Ps. I'm real fun at parties!

by ngruhn 2y ago

jeroenhd 2y ago

It's correct, though. The URI scheme for HTTPS may always include a domain name, but my-app: is just as valid a URL as anything else. A protocol where everything is optional and the default opens a screen with all fields empty is valid, though unlikely. For instance, an empty mailto: will reliably launch an email client, even if no address is specified. I think it's the second most used protocol in web links, after HTTP(S). If you want to to URL parsing by brute forcing URL constructors, you probably don't want application URLs in the first place. You should probably start with https:// https:// and http:// http://, or make use of the weird double slash HTTP introduced into the URL by matching on :// instead.

mstade 2y ago
Well, ackchyually... If you want to get real anal about it the API should probably called URI instead of URL. The latter should describe where to access the resource, not just how to identify it, and to truly be able to do that you must also know something about the scheme. At the very least you must know whether the scheme imposes further restrictions on the individual parts of the URI, otherwise you can only determine whether it's a valid URI but not truly say whether it's a valid URL. In practice no one really cares much about the distinction between identifiers and locators, and arguably it was a mistake to try and make that distinction in the spec. But it is in there after all and I find it a bit ironic that the authors of the JS spec chose to ignore it. There's probably good reason for it, but still. Ps. I'm real fun at parties!