feat(hasProtocol): optionally allow protocol relative url

[danielroe]

No description provided.

[danielroe]

Happy to flip default or disable parseURL support for protocol relative URLs but I think better to accept in parseURL because of prevalence of them in the wild.

[pi0]

// is not really a valid URL even considering scheme is optional since has no path:

URI = scheme:[//authority]path[?query][#fragment]

[pi0]

Trying in chrome, <a href="//> redirects to about:blank#blocked (or any pattern like ///)

[codecov-io]

Codecov Report

Merging #16 (4445e56) into main (e0a1599) will increase coverage by 0.12%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #16      +/-   ##
==========================================
+ Coverage   86.91%   87.03%   +0.12%     
==========================================
  Files           7        7              
  Lines         214      216       +2     
  Branches       60       62       +2     
==========================================
+ Hits          186      188       +2     
  Misses         28       28              

Impacted Files	Coverage Δ
src/parse.ts	87.50% <100.00%> (ø)
src/utils.ts	98.43% <100.00%> (+0.05%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e0a1599...4445e56. Read the comment docs.

[pi0]

@danielroe More I'm thinking isURL, should do real URL validation rather than checking protocol existence. Something like http://. is invalid and it can cause troubles if isURL being used in conditions to trsut a user input (see examples in this list: https://mathiasbynens.be/demo/url-regex)

What do you think if in this PR:

• Keep/Add support for protocol relative parsing
• Add flag to hasProtocol util to optionally allow relative syntax

And move isURL task to new PR with proper regex (or parser based on perf and complexity)?

[danielroe]

@pi0 Sounds like a good plan. I'll make a stab.

(Separate comment) I wonder about differentiating utils that parse/validate input in accordance with spec compliance vs 'cheap' utils that assume pre validation.

[pi0]

@danielroe Agree for naming. hasProtocol since even it is a cheap implementation, it's name is clear it is not validating entire URL.

BTW generally, there is not single standard for URL to follow and this PR is an example about conventions that are supported. (another example plus as space encoding)
My main goal for ufo is making stable utils for unversal/consistent behavior and sticking to standards as much as possible.