Shmeeps.org

Ran into an issue using the Safari browser that took a while to track down. Whenever our server would come under heavy load, requests to the server could start to take much longer to process, upwards of 10-15 seconds for pages with a lot of data. While this was a whole other issue on its own (which sadly, as we don’t manage our servers, we couldn’t really address), it was made even worse by the fact that many of our users use Safari on our webapps, and these pages would timeout after 10 seconds or so where other browsers would load fine.

The AJAX call being affected was similar to the one below. Note the 30 second timeout.

[code lang=”javascript”]
$.ajax({
url: ‘http://www.mywebsite.com’,
async: false,
success: function() {
console.log(‘Success!’);
},
timeout: 30000
});
[/code]

The key here is the async flag. After a bit of research, I found out that some time ago, Safari changed the way synchronous requests were handled by ignoring the timeout flag and considering the requests timed out if it took more than 10 seconds. I’m assuming this was done for user-experience, as synchronous requests block the page from responding until completed. By forcing the timeout to a small value, they ensure that the page doesn’t hang for long periods at a time. While I don’t think that a browser should dictate the timeout length, and that frankly. it’s still a bad experience when you can’t get a page to load that would load as normal in another browser, it’s still something that needs to be dealt with.

There’s basically two ways to deal with this issue, the first is to modify the request handler server-side to periodically send some blank data to let Safari know the request is still active. This is moderately difficult to set up, and can run into some issues with response parsing. The easier method is to just use synchronous calls. There’s only a small number of cases where asynchronous calls should be used, and if you can’t think of a reason for using one, you should stick with synchronous calls anyway.