Bypass Facebook's FBML time out error
Sep 20, 2009
Bypassing Facebooks response time limit when developing applications
There exists a certain well known problem when developing Facebook applications, Facebook has a certain time limit regarding responses from the application web server.
I am a new Facebook developer , started just a week ago and I have already encountered this issue , I will assume you have a basic knowledge of Facebook application development.
I have chosen to use FBML which is the Facebook alternative to HTML , it's a tag based markup language used to render components which relate to the Facebook platform, the other choice when writing Facebook application is using and IFrame and I suspect the problem doesn't happen there.
The difference lies in the interaction process , when using IFrames Facebook renders the IFrame inside it's own Facebook designed component , the IFrame source is actually a callback URL you set up earlier with a few parameters passed along to allow you to identify the user. From that point communication can happen between you and the IFrame which is your own private server or the Facebook server itself.
When using FBML , upon a request the Facebook server calls your callback URL independently from your browser , renders all FBML data and presents the formatted data back to your browser , you have no interaction with the server your application is hosted on , just the Facebook server.
Here lies the problem , I have yet verified the full conditions for this problem but I have read several forum posts related to a certain time limit Facebook imposes on the connection between the Facebook server and your server , when Facebook goes to retrieve your application data there seems to be a certain time limit where most forum users describe as 8 seconds , be it true or not it poses a problem. I was designing an application which used somewhat 'heavy' Facebook API calls since the Facebook API is based on a REST structure there was the added time of the whole request processing regardless of the actual actions I performed.
Without knowing of that time limit I went and built my application and to my surprise when I ran the code I got an error from facebook saying that the URL I reached did not respond to the Facebook request , I thought it might be true , that is just did not respond but after further testing I found out there was nothing wrong with my page and after further google searching I arrived at the issue at hand.
After some thought I came up with a solution which worked for me , I had to offload my processing to some back process that wouldn't waste any time during the request since that would delay the connection between the Facebook server and my page and would cause the error , I did not want to use some back-end Job Processing mechanism since I needed my processing to happen right there and then but on unrelated to my request.
Since I was developing on windows I did not consider using any threading related action because let's face it , windows threading is not PHP strong side and although the application finally ran on a linux server I did not want to mess with that. I came up with the following solution: cURL.
If you have been developing long enough your bound to know cURL but if you don't I'll explain quickly.
cURL is a command line tool used to form and send requests using various protocols(I mainly use it for HTTP) it also supports many handy features such as cookie handling , proxy , form upload and more.
It also contains a handful library to be used as an API to cURL's options.
If I am not mistaken as of PHP 4.2.0 cURL is in included as part of the base PHP library(source).
The basic functions of cURL include sending requests one a time and handling the response , how can that help me get the job done if when I issue a request I have to wait for the response and waste precious Facebook time?
cURL also included an advanced feature called multi processing or parallel processing , it allows to set up multiple requests and run them in parallel as the name suggests using non-block sockets(you'd normally be using blocking sockets such as cURL basic request sending functions , meaning you'd be blocked until a response is returned so your code would wait until it is returned to continue running,non-blocking allows you to ignore the need to wait for the response).
What I did was move the 'heavy' code to another script residing on the same webserver and where that code used to lie I placed a code to use cURL's multi processing to call that script , that resulted in the a code that does exactly the same actions but the time wasted running those actions was now not part of the Facebook request and thus did not cost me any Facebook time allowing me to get my code running with no errors :)
The basic structure I used to achieve this is detailed below:
It is pretty basic and does not require much explaining(all answered can be found on the PHP cURL dedicated page) , it's basically initializing a multi handle , creating a request , adding the request to the request stack, running it and closing it.
I had to extend the code since I was required to handle the output from the offloaded script , do mind that using non-blocking sockets does not mean you can't get the response back, it means you have to handle it differently , I made the changes to suit my needs I'm sure you can figure out how to make yours.
This is how you can safely and peacefully bypass the Facebook request time limit :)
There exists a certain well known problem when developing Facebook applications, Facebook has a certain time limit regarding responses from the application web server.
I am a new Facebook developer , started just a week ago and I have already encountered this issue , I will assume you have a basic knowledge of Facebook application development.
I have chosen to use FBML which is the Facebook alternative to HTML , it's a tag based markup language used to render components which relate to the Facebook platform, the other choice when writing Facebook application is using and IFrame and I suspect the problem doesn't happen there.
The difference lies in the interaction process , when using IFrames Facebook renders the IFrame inside it's own Facebook designed component , the IFrame source is actually a callback URL you set up earlier with a few parameters passed along to allow you to identify the user. From that point communication can happen between you and the IFrame which is your own private server or the Facebook server itself.
When using FBML , upon a request the Facebook server calls your callback URL independently from your browser , renders all FBML data and presents the formatted data back to your browser , you have no interaction with the server your application is hosted on , just the Facebook server.
Here lies the problem , I have yet verified the full conditions for this problem but I have read several forum posts related to a certain time limit Facebook imposes on the connection between the Facebook server and your server , when Facebook goes to retrieve your application data there seems to be a certain time limit where most forum users describe as 8 seconds , be it true or not it poses a problem. I was designing an application which used somewhat 'heavy' Facebook API calls since the Facebook API is based on a REST structure there was the added time of the whole request processing regardless of the actual actions I performed.
Without knowing of that time limit I went and built my application and to my surprise when I ran the code I got an error from facebook saying that the URL I reached did not respond to the Facebook request , I thought it might be true , that is just did not respond but after further testing I found out there was nothing wrong with my page and after further google searching I arrived at the issue at hand.
After some thought I came up with a solution which worked for me , I had to offload my processing to some back process that wouldn't waste any time during the request since that would delay the connection between the Facebook server and my page and would cause the error , I did not want to use some back-end Job Processing mechanism since I needed my processing to happen right there and then but on unrelated to my request.
Since I was developing on windows I did not consider using any threading related action because let's face it , windows threading is not PHP strong side and although the application finally ran on a linux server I did not want to mess with that. I came up with the following solution: cURL.
If you have been developing long enough your bound to know cURL but if you don't I'll explain quickly.
cURL is a command line tool used to form and send requests using various protocols(I mainly use it for HTTP) it also supports many handy features such as cookie handling , proxy , form upload and more.
It also contains a handful library to be used as an API to cURL's options.
If I am not mistaken as of PHP 4.2.0 cURL is in included as part of the base PHP library(source).
The basic functions of cURL include sending requests one a time and handling the response , how can that help me get the job done if when I issue a request I have to wait for the response and waste precious Facebook time?
cURL also included an advanced feature called multi processing or parallel processing , it allows to set up multiple requests and run them in parallel as the name suggests using non-block sockets(you'd normally be using blocking sockets such as cURL basic request sending functions , meaning you'd be blocked until a response is returned so your code would wait until it is returned to continue running,non-blocking allows you to ignore the need to wait for the response).
What I did was move the 'heavy' code to another script residing on the same webserver and where that code used to lie I placed a code to use cURL's multi processing to call that script , that resulted in the a code that does exactly the same actions but the time wasted running those actions was now not part of the Facebook request and thus did not cost me any Facebook time allowing me to get my code running with no errors :)
The basic structure I used to achieve this is detailed below:
$url = SCRIPT_URL;
$mcurl = curl_multi_init();
$ch1 = curl_init();
curl_setopt($ch1, CURLOPT_URL,$url);
curl_setopt($ch1, CURLOPT_HEADER, 0);
curl_setopt($ch1, CURLOPT_POST, 1);
curl_setopt($ch1, CURLOPT_POSTFIELDS, $post);
$res = curl_multi_add_handle($mcurl, $ch1);
$running=null;
do {
curl_multi_exec($mcurl,$running);
} while($running > 0);
curl_multi_remove_handle($mcurl, $ch1);
curl_multi_close($mcurl);It is pretty basic and does not require much explaining(all answered can be found on the PHP cURL dedicated page) , it's basically initializing a multi handle , creating a request , adding the request to the request stack, running it and closing it.
I had to extend the code since I was required to handle the output from the offloaded script , do mind that using non-blocking sockets does not mean you can't get the response back, it means you have to handle it differently , I made the changes to suit my needs I'm sure you can figure out how to make yours.
This is how you can safely and peacefully bypass the Facebook request time limit :)
Comments