There has been a UDF released for a while now that would check to see if a URL is valid. Ben wrote urlExists over a year ago. Along with isValid(), you can check both the form and existence of a URL.
For the heck of it - I thought I'd make a quick demo in Spry showing how you can do without refreshing the browser. First take a quick look at the online demo:
http://ray.camdenfamily.com/demos/spryurlcheck/
Don't hit submit on the button, just enter a URL and click off of it. Do note that the you have to enter a valid URL before the server will check it. (So don't enter "toaster", enter "http://www.toaster.com".)
The code behind this is rather simple. First, look at the form field for URL:
<input type="text" name="homepage" id="homepage" onBlur="validateURL()"> <span id="urlcheckresult"></span>
I use an onBlur to call a JavaScript function. Also note the span next to the form field. validateURL is pretty simple:
function validateURL() {
var url = $("homepage").value;
if(url == '') return;
Spry.Utils.updateContent('urlcheckresult','urlcheck.cfm?site='+encodeURI(url));
}
I grab the value of the URL and ensure it isn't blank. Next I use updateContent. This was added in the last Spry release. It is a simple way to load a new URL into a div or span. Here I'm simply pointing the span next to my form field to a server side file. The server side file is also rather simple. To cut down on the size I removed Ben's UDF:
<cfparam name="url.site" default="">
<style>
b.good {
color: green;
}
b.sucky {
color: red;
}
</style>
<cfif len(url.site) and isValid("url", url.site)>
<cfif urlExists(url.site)>
<cfoutput><b class="good">Valid URL!</b></cfoutput>
<cfelse>
<cfoutput><b class="sucky">Appears to be an invalid URL</b></cfoutput>
</cfif>
</cfif>
The only thing that I don't like about this demo is the speed. Adobe made updateContent blocking, so you can't do anything while the page is loading. Of course, someone could easily add this to the Spry code.
Archived Comments
What do you mean by "Adobe made updatecontent blocking"?
What is blocking?
It means that when Spry makes the HTTP call it waits for the result. So you can't do anything else until it is done. This is JUST how updateContent was written. Spry's other net functions allow you to do blocking/non-blocking calls depending on what you want.
is blocking/non-blocking the same as sync/async?
Yes. I call it Ray-speak.
I think you are aware that a malicious user could use the urlcheck.cfm to start an DoS attack or to exploit other vulnerabilities of any web server and remain undetected.
Using such a page I can even submit comments to blogs if they accept URL parameters.
I think you should include a key or a method to secure your CF script to make sure you are called from within the form only.
I follow your blog and I have to congratulate about your Spry interest and support. Keep up the good work.
Absolutely. The simplest solution would be to require a logged in user and log the checks.
This is fine, but what boggles my mind is, if you're checking the http status message anyway, why not just check for a 200 ("OK") status, and take care of the whole thing with 1 conditional?
Why does it matter? He still needs the conditionals to ensure a valid response came back from CFHTTP anyway, so you wouldn't lose any conditionals, you would just change the status code being checked.
it *could* matter in cases where you needed to differentiate the response to a greater degree.
...meaning, say my business logic required the url to not only be valid, but be currently accessible from the server hosting my app.
In that case, I'd want to check for a 200 OK reponse specifically. If I checked for just ! 404, that would let 500 (internal server error, think it's 500) through, as well as access-denied (i.e. directory browsing forbidden) and similar responses through the check.
I know this is contriving additional conditions beyond the url just being "valid" - but I'd tend to think the udf would be useful in a more broad range of uses if it checked specifically for 200 ok.
Just my opinion though - as I said above, the way that udf works now is fine for what it seems to be intended to do.