«

In comp.lang.javascript message <d69e1a77-5741-442e-b783-b9027ab96a30@r2
1g2000yqr.googlegroups.com>, Tue, 13 Sep 2011 23:12:08, jwcarlton
<> posted:

>This is a tricky one for me. I'm validating a form, and want to check
>if a field entered is a legitimate website address. I don't
>necessarily need to ensure that the site works (I can do that later),
>but I do want to see if what's entered is a likely URL.

You don't give any indication of your location, so we can guess nothing
about your circumstances. If, for example, you are a resident Cuban,
you may need to allow for North Korean addresses, But, if you are
American, it might even be illegal to accept them.

Use Wikipedia <http://en.wikipedia.org/wiki/Request_for_Comments> and
its links to search the RFCs for the allowable forms of website address,
being sure to use only currently-applicable RFCs.

Remember to allow for dotted quad and IPv6 equivalent.

If there is any chance that your test may reject a valid and legitimate
address, consider allowing the user to override refusal.

Note that the majority of typoes applied to valid addresses yield
possible addresses. Therefore, it is really necessary to rely on the
user being careful enough.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms and links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

In comp.lang.javascript message <Xns9F60C00978E66nevermind@94.75.214.39>
, Wed, 14 Sep 2011 22:53:01, Mike Duffy <> posted:

>jwcarlton <> wrote in news:d69e1a77-5741-442e-b783-
>:
>
>> This is a tricky one for me. I'm validating a form, and want to check
>> if a field entered is a legitimate website address. I don't
>> necessarily need to ensure that the site works (I can do that later),
>
>If you are going to do that later anyway, why even bother to try to parse
>it first? Are you not just wasting effort?
>
>Let the DNS server do the work.

If one attempts to validate over the Net, the user may have to wait
several seconds for an answer. That is annoying when not necessary.


One should realise that there three possible states of validation : yes,
no, and don't know.

Only a net test can assure the user that the URL is valid; and even then
it may not remain valid - and it still may not be the right one.

But some strings, liable to be entered in error, can be ruled out as
possible URLs by a local check, with more or less confidence. An empty
string cannot, I think, be a URL, even if a default protocol is added.
Probably there must be at least one dot in the URL, though for all I
know something other than \u002E might be allowed in Asian URLs
nowadays. The final character probably has to be a letter, but perhaps
not necessarily in the ranges A-Z a-z.

One should test for cannot-be-right input at the client end, as far as
that can be reasonably done in safety - which includes not only the
soundness of the intended algorithm, but also the coder's ability to get
it right.

--
(c) John Stockton, nr London UK. ?@merlyn.demon.co.uk IE8 FF3 Op12 Sf5 Cr12
news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>.
<http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

Dr J R Stockton <> wrote in news:qaYF
$:

> But some strings, liable to be entered in error, can be ruled out as
> possible URLs by a local check, with more or less confidence.

True. But the most common types if miss-spelling (as well as the most
common spells of miss-typing) will not be within the "http://" part of the
URL, which might not even be there if it is assumed to be such by the
application. Usually an error will be an ommission, duplication, or
transposition of alphanumeric characters. Mistakes such as this will always
evaluate as valid and will need to be run through the network in any case.

In other words, yes, you can very quickly (client side) notice it when a
"." has been entered as a ",". But most typing mistakes will not be
noticed. Is it worth making your code more complicated to do this?

It will not speed up the obligatory check which will need to be done
afterwards. And it introduces more code which increases the chance of your
user seeing one of those pesky JS error boxes.

--
http://pages.videotron.ca/duffym/index.htm#

In comp.lang.javascript message <Xns9F62E15E755DCnevermind@94.75.214.39>
, Sat, 17 Sep 2011 02:09:16, Mike Duffy <> posted:

>Dr J R Stockton <> wrote in news:qaYF
>$ :
>
>> But some strings, liable to be entered in error, can be ruled out as
>> possible URLs by a local check, with more or less confidence.
>
>True. But the most common types if miss-spelling (as well as the most
>common spells of miss-typing) will not be within the "http://" part of the
>URL, which might not even be there if it is assumed to be such by the
>application. Usually an error will be an ommission, duplication, or
>transposition of alphanumeric characters. Mistakes such as this will always
>evaluate as valid and will need to be run through the network in any case.
>
>In other words, yes, you can very quickly (client side) notice it when a
>"." has been entered as a ",". But most typing mistakes will not be
>noticed. Is it worth making your code more complicated to do this?

Yes, provided that the code added is short, within the competence of the
code, and written with a sufficient knowledge of the RFCs.

A moderately careful user will look at the input fields before
submission, but only moderately carefully. Comma-for-dot is an easy
error to make and to miss. Another is entering a wrong value entirely,
perhaps a telephone number. Another is not entering anything.

Such are worth finding, for the user's point of view, because they allow
an immediate response.

>It will not speed up the obligatory check which will need to be done
>afterwards. And it introduces more code which increases the chance of your
>user seeing one of those pesky JS error boxes.

If one cannot, with testing, reliably code a client-side test for
"at least one dot", then one should not be coding such applications.

If the server-side code logs the reasons for its rejections, one may see
other client-side tests that would be useful.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)