Christian asks:
This is slightly related to the AJAX discussion you've blogged about this month. And so I ask this question in hopes you might address it on your blog. Yesterday, we saw a number of client sites stumble due to the issues that Facebook was having. Slow page loading or even error messages within the Facebook display areas were common. In one case, the client has the Facebook "Like" button deployed by using the Facebook Javascript SDK and in the iframe that Facebook writes out, the error "DNS Error - Service Unavailable" was displayed.
For Coldfusion developers who are asked to deploys these sorts of interconnected solutions, what are some methods to protect the client site when the service you are calling goes awry? Facebook isn't the only case, but it has high-visibility today and I imagine other readers saw the same issue and took the same sorts of calls from clients yesterday.
Good question. I responded back to him by asking if we could split this into two concerns:
- Handling remote sites from ColdFusion (like when you use cfhttp or cffeed)
- Handling remote sites from JavaScript
Each of the above allow you to embed remote resources and tools into your site and each requires a totally different way of handling it. Let's begin with the first type. I know I ran into issues with this a few times this year. First I had a few sites brought down by a bad cffeed call. Then my own blog had issues with a cfhttp call. While one of the issues I ran into involved RSS feeds that required authentication, my biggest problem was forgetting the simple timeout attribute. In all cases you want to at least do the following:
- Wrap your call in a try/catch.
- Use a timeout to ensure the network call doesn't spend too long trying to get the request.
- Cache the result if your business rules allow. (And with caching being ridiculously easy in ColdFusion you really have no excuse not to.)
It wouldn't hurt to add some logging to that logic above too - especially if you aren't sure how stable your remote resource is.
Now let's go to the client side - and here I'm going to have to ask for help from my readers. In terms of JavaScript you may embed into your code, let's say a library that adds a widget or somesuch, don't forget you can make use of error handling at the window level. I've yet to actually do this in a real project but it seems like something I should consider:
<script>
window.onerror = function(e) {
alert('error');
console.dir(e);
return false;
}
</script>
In a simple test this seemed to work well for me. (Well, you would want to do a bit more than just alert probably.) I then tried the same with a bad iframe:
<iframe src="http://www.gdfgdgdfgdfgoogle.com" id="remote"></iframe>
But this did not fire my main onerror handler. I tried using an onerror on the iframe tag itself, but I didn't have any luck in that regards. Perhaps one of my readers would know? Perhaps we could listen for a loaded event and if it doesn't happen within 10 seconds simply hide the iframe completely. Thoughts?
Archived Comments
This is how you could deal with it on the client side: http://bit.ly/byqTXJ
For Twitter or Facebook, you could do something similar where you check if a function from their library exists and then display a message (or nothing?) if their site is down.
What about using the onload attribute of the iframe? You then may be able to use some dom manipluation to find out the content of the frame and see if it is accurate.
@Dave Ferguson - for some reason the load/error handlers do not fire in jQuery with an iframe.
@Ray: How about something like this? http://pastebin.com/rhkRkSQy Can't verify it works 100% because Facebook is blocked here at work - but in theory it should work.
I copy/pasted that FB iframe url from another page, but you get the idea. Go here to generate your own url to test with: http://developers.facebook....
Again...facebook, blocked, yada yada...
@JB: Yep, looks smart. Thanks
@Dave: I would think you would still need a timer to see if the variable is set. Oh - you could make the iframe hidden at first and only show it on a good load. That would probably be better.
@Todd: That looks good too - can you try it when you get off work and let us know?
Here's how I would handle the possibility of external resources being down (even specifically using Facebook as an example):
http://fusiongrokker.com/po...
That's a damn nice tip. Thanks for sharing that Adam.
Is there anything jQuery can't do?