You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Well that's interesting! xyz.123 does fail parsing though. I didn't find anything on the golang issues, but this might be something to file.
Looking at RFC 1738 refers to the host being defined in Section 3.5 of RFC 1034 which reads:
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case
<digit> ::= any one of the ten digits 0 through 9
That makes me think that it really is an invalid domain, but parsing fails when a scheme (e.g. http://) is added.
I was looking at this library from AppOps Weekly, but found an issue with url parsing.
From a CVE earlier this year there's a valid url I wanted to try, but this lib fails parsing it. (stdlib
net/url
's method Parse is fine)Example: http://example.com#@evil.com/x.txt
I'm curious though, why not write
IsUrl(str)
like this:The text was updated successfully, but these errors were encountered: