31–40 of 67 posts
@stephenhay seems to be the winner here if you don't need IP addresses (or weird dashed URLS). It's only 38 characters long and easy to understand. @^(https?|ftp)://[^\s/$.?#].[^\s]*$@iS The simpler the better, if you're going to use something that is not ideal.
I was just struggling with this -- specifically, our users' "UX" expectation that entering "example.com" should work when asked for their website URL. Most URL validation rules/regex/librairies/etc. reject "example.com". However, if you head over to Stripe (for example), in the account settings, when asked for your company's URL, Stripe will accept "example.com", and assume " http:// " as the prefix (which yes, can h…
if (validateURL(url)) {
return url;
} else if (validateURL("http://" + url)) {
return "http://" + url;
} else {
return null;
}I was once failed on a technical interview, partly because on the coding test I was asked to write a url parser "from scratch, the way a browser would do it" and I explained it would take way too long to account for every edge case in the URL RFC but that I could do a quick and dirty approach for common urls. After I did this, the interviewer stopped me and told me in a negative way that he expected me to use a regex…
How do browsers parse URLs then?
I was once failed on a technical interview, partly because on the coding test I was asked to write a url parser "from scratch, the way a browser would do it" and I explained it would take way too long to account for every edge case in the URL RFC but that I could do a quick and dirty approach for common urls. After I did this, the interviewer stopped me and told me in a negative way that he expected me to use a regex…
My imagined remedies are no 1:1 interviews and recording these sessions for "possible quality assurance and training purposes".
Even if you built a URL validation regex that follows rfc3986[1] and rfc3987[2], you will still get user bug reports because web browsers follow a different standard. For example, http://example.com./ > , http:///example.com/ > and https://en.wikipedia.org/wiki/Space (punctuation) > are classified as invalid urls in the blog, but they are accepted in the browser. As the creator of cURL puts it, there is no URL standa…
Uh oh, Regex is approaching sentience.
I was once failed on a technical interview, partly because on the coding test I was asked to write a url parser "from scratch, the way a browser would do it" and I explained it would take way too long to account for every edge case in the URL RFC but that I could do a quick and dirty approach for common urls. After I did this, the interviewer stopped me and told me in a negative way that he expected me to use a regex…
Even if you built a URL validation regex that follows rfc3986[1] and rfc3987[2], you will still get user bug reports because web browsers follow a different standard. For example, http://example.com./ > , http:///example.com/ > and https://en.wikipedia.org/wiki/Space (punctuation) > are classified as invalid urls in the blog, but they are accepted in the browser. As the creator of cURL puts it, there is no URL standa…
Even if you built a URL validation regex that follows rfc3986[1] and rfc3987[2], you will still get user bug reports because web browsers follow a different standard. For example, http://example.com./ > , http:///example.com/ > and https://en.wikipedia.org/wiki/Space (punctuation) > are classified as invalid urls in the blog, but they are accepted in the browser. As the creator of cURL puts it, there is no URL standa…
http://example.com./ > is a valid URL, see for example: https://jdebp.uk/FGA/web-fully-qualified-domain-name.html