Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Check if value is a website URL

Reply
Thread Tools

Check if value is a website URL

 
 
Dr J R Stockton
Guest
Posts: n/a
 
      09-15-2011
In comp.lang.javascript message <d69e1a77-5741-442e-b783-b9027ab96a30@r2
1g2000yqr.googlegroups.com>, Tue, 13 Sep 2011 23:12:08, jwcarlton
<(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
 
Dr J R Stockton
Guest
Posts: n/a
 
      09-16-2011
In comp.lang.javascript message <Xns9F60C00978E66nevermind@94.75.214.39>
, Wed, 14 Sep 2011 22:53:01, Mike Duffy <(E-Mail Removed)> posted:

>jwcarlton <(E-Mail Removed)> wrote in news:d69e1a77-5741-442e-b783-
>(E-Mail Removed):
>
>> 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.
 
Reply With Quote
 
 
 
 
Mike Duffy
Guest
Posts: n/a
 
      09-17-2011
Dr J R Stockton <(E-Mail Removed)> wrote in news:qaYF
$(E-Mail Removed):

> 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#
 
Reply With Quote
 
Dr J R Stockton
Guest
Posts: n/a
 
      09-18-2011
In comp.lang.javascript message <Xns9F62E15E755DCnevermind@94.75.214.39>
, Sat, 17 Sep 2011 02:09:16, Mike Duffy <(E-Mail Removed)> posted:

>Dr J R Stockton <(E-Mail Removed)> wrote in news:qaYF
>$(E-Mail Removed) :
>
>> 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)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Getting ID, calling url, search for value, return value Tim Fröglich ASP .Net Web Services 1 01-10-2006 09:18 PM
check if string contains numeric, and check string length of numeric value ief@specialfruit.be C++ 5 06-30-2005 01:08 PM
i want to check whether a value is passing via an url cc dd via .NET 247 ASP .Net 1 09-23-2004 08:36 AM
URL - substitution of a correct URL by a GUID like URL in favorites. Just D. ASP .Net Mobile 0 08-11-2004 04:26 PM
redirect URL's, return URL's, and URL Parameters Jon paugh ASP .Net 1 07-10-2004 05:29 AM



Advertisments