5 ms·

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

by 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
> Validating absolute URLs is easy. I disagree. Your approach does not address[0]: By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. Nor URL's with user and/or password elements[1]. Nor the different, yet equivalent, path encodings such as "/has+space" and "/has%20space". Nor does it normalize path segments before determining value equality, such as "/foo/bar" being equivalent to "/foo/blah/../bar" as well as be equivalent to "/../../../foo/../foo/blah/../.././foo/./bar". So no, validating absolute URL's is not "easy." 0 - https://datatracker.ietf.org/doc/html/rfc1034#section-3.1 https://datatracker.ietf.org/doc/html/rfc1034#section-3.1 1 - https://datatracker.ietf.org/doc/html/rfc1738#section-3.1 https://datatracker.ietf.org/doc/html/rfc1738#section-3.1
- Sephr 3y ago
  The utility mentioned isn't the approach I would recommend for 'validating absolute URLs' -- for that I would simply use try..catch with the URL() constructor and no base URL. My linked utility is specifically for validating that a URL is valid (won't throw an error when passed to the URL constructor) and doesn't need additional encoding. This helps with my use case which is a 'create URL classification' UI that allows users to input URL matchers in a multitude of formats. For additional context, some inputs are invalid even with a base URL. e.g. new URL('//:0', 'https://- https://-') will throw an error. Your first critique doesn't seem relevant as this is mostly for checking if a URL is 'valid' (i.e. doesn't throw an error when used). Also, for your second critique, the username + password is actually part of the origin as used by both of my snippets. For example, isValidURL('https://a:b@c.d/ https://a:b@c.d/') and isValidURL('https://a:b@[::1]/ https://a:b@[::1]/') both return true for me. Do you have a URL that gave a bad result? If so, feel free to mention it here and in the comments for the gist so that users of my snippet can be made aware of its limitation.
pwdisswordfishc 3y ago
"-" is not a valid host.
- Sephr 3y ago
  That is a good point. It's also a potential source of input desynchronization vulnerabilities as 'valid' (does not throw an error when passed to the URL constructor) URLs can contain invalid hosts.

by Sephr 3y ago

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

> Validating absolute URLs is easy. I disagree. Your approach does not address[0]: By convention, domain names can be stored with arbitrary case, but domain name comparisons for all present domain functions are done in a case-insensitive manner, assuming an ASCII character set, and a high order zero bit. Nor URL's with user and/or password elements[1]. Nor the different, yet equivalent, path encodings such as "/has+space" and "/has%20space". Nor does it normalize path segments before determining value equality, such as "/foo/bar" being equivalent to "/foo/blah/../bar" as well as be equivalent to "/../../../foo/../foo/blah/../.././foo/./bar". So no, validating absolute URL's is not "easy." 0 - https://datatracker.ietf.org/doc/html/rfc1034#section-3.1 https://datatracker.ietf.org/doc/html/rfc1034#section-3.1 1 - https://datatracker.ietf.org/doc/html/rfc1738#section-3.1 https://datatracker.ietf.org/doc/html/rfc1738#section-3.1

Sephr 3y ago
The utility mentioned isn't the approach I would recommend for 'validating absolute URLs' -- for that I would simply use try..catch with the URL() constructor and no base URL. My linked utility is specifically for validating that a URL is valid (won't throw an error when passed to the URL constructor) and doesn't need additional encoding. This helps with my use case which is a 'create URL classification' UI that allows users to input URL matchers in a multitude of formats. For additional context, some inputs are invalid even with a base URL. e.g. new URL('//:0', 'https://- https://-') will throw an error. Your first critique doesn't seem relevant as this is mostly for checking if a URL is 'valid' (i.e. doesn't throw an error when used). Also, for your second critique, the username + password is actually part of the origin as used by both of my snippets. For example, isValidURL('https://a:b@c.d/ https://a:b@c.d/') and isValidURL('https://a:b@[::1]/ https://a:b@[::1]/') both return true for me. Do you have a URL that gave a bad result? If so, feel free to mention it here and in the comments for the gist so that users of my snippet can be made aware of its limitation.

pwdisswordfishc 3y ago

"-" is not a valid host.

Sephr 3y ago
That is a good point. It's also a potential source of input desynchronization vulnerabilities as 'valid' (does not throw an error when passed to the URL constructor) URLs can contain invalid hosts.