4 ms·

A new method to validate URLs in JavaScript

• CharlesW 3y ago
  > The only thing remaining is the question "What is a valid URL?" but I'll leave this one for another time! Because it's a tough one. Is it? According to https://www.w3.org/TR/2011/WD-html5-20110525/urls.html https://www.w3.org/TR/2011/WD-html5-20110525/urls.html, a URL is a valid URL if at least one of the following conditions holds: • The URL is a valid URI reference [RFC3986]. • The URL is a valid IRI reference and it has no query component. [RFC3987] • The URL is a valid IRI reference and its query component contains no unescaped non-ASCII characters. [RFC3987] • The URL is a valid IRI reference and the character encoding of the URL's Document is UTF-8 or UTF-16. [RFC3987]
  • bkallus 3y ago
    Except the RFCs are not the only URL standards. Browsers all implement the WHATWG living standard, which is subtly incompatible with the RFCs.
    • _a_a_a_ 3y ago
      if they diverged from standards that's on them. What is WHATWG anyway, and what is a 'living standard', and is it a standard at all, or a lack of standard?
      • voxic11 3y ago
        https://url.spec.whatwg.org/ https://url.spec.whatwg.org/
• stevebmark 3y ago
  Valid according to who? If you're automatically linking text that looks like URLs, this will fail since most people don't type the protocol when sharing a website URL.
  • misonic 3y ago
    agreed, as to normal user, I would think both in the post example are valid URLs
  • chrismorgan 3y ago
    I detest that style of auto-linking. You get so many false positives—and sometimes troublesome ones at that. With the possible exception of text with a `www.` prefix, the entire thing is just a misfeature. Let people copy an entire URL if they mean a URL.
• Sephr 3y ago
  Validating absolute URLs is easy (edit: with a try..catch statement). I was hoping that this standard would introduce a utility for validating both relative and absolute URLs. Here's how I do it: https://gist.github.com/eligrey/443d51fab55864005ffb3873204b877a#file-uri-validator-ts https://gist.github.com/eligrey/443d51fab55864005ffb3873204b... As you can see, this implementation fails for URLs with - as their host. There should be a cleaner solution here that doesn't involve creating new URL instances with test scaffolding (the input base URL).
  • mmastrac 3y ago
    There's a second overload that takes a base: https://developer.mozilla.org/en-US/docs/Web/API/URL/canParse_static https://developer.mozilla.org/en-US/docs/Web/API/URL/canPars...
    • Sephr 3y ago
      That's quite useful! I'm going to integrate that into my code and fallback to the previous implementation if canParse() is not available.
  • chrismorgan 3y ago
    Not fond of your function name isValidURL: it’s more about checking if a URL is represented canonically (… except that it also allows https://example.com https://example.com with no trailing slash), rather than just if it’s valid.
    • hducy4 3y ago
      [dead]
    • Sephr 3y ago
      What would you propose as a better name? I recognize that this doesn't align fully with the spec. This has been helpful for my specific use cases.
  • AdieuToLogic 3y ago
• handy2000 3y ago
  There is a distinction to be made between a parseable string and a valid URL in more complete terms. While it's nice to have a new standard function that checks whether a string is parseable as a URL, it can't, of course, validate that string in terms of whether the TLD is a real one, and not something like "https://super.hacker/ https://super.hacker/". So maybe the post should have called it what it is: validating parse-ability, since the method itself is called "canParse()".
  • hducy4 3y ago
    super.hacker is a valid url. Url validity isn't dictated by ICANN.