AJAX Extended - FAQ

Frequently asked questions

If you can’t find the information you’re looking in this FAQ, please, contact me. I will be glad to help.

HELP! It doesn’t work! What should I do?

Well, basically neither the server script, nor the client script does anything special that is not supported by your server or your browser. So don’t worry, it should work in 99,9% cases. Here are the possible workarounds:

Make sure you installed AJAXExtended correctly

If you haven’t deleted the test files from the server yet, this check is a piece of cake. Fire up you browser and type in the following address: http://www.yourwebserver.com/path-to-the-php-files/tests/ (notice the tests folder). If it shows a green box saying everything is ok, it means just that: AJAXExtended is installed properly. If it shows a red box or something else, please, check the installation instructions.

Make sure you got an error handling function

During a server-to-server request the proxy might encounter different kind of problems and it can successfully cope with some of them. So the server won’t just die unexpectedly and forget about the client request. AJAXExtended allows you to handle these errors. Just like that:

var request = new XMLHTTP()
request.onerror = function(description) {
alert('Error: ' + description)
}

For instance, if the requested server is down or it’s name cannot be resolved, AJAXExtended will trigger the error handler and pass on the following description: “Error occurred while connecting to the specified host”.

How does the script access other domains?

The trick is that the script doesn’t use the native XMLHTTP object. It works just the same, but it employs a different technology: dynamic SCRIPT tags. It is not a security vulnerability in any way. It’s an absolutely standard feature, supported by all browsers.

How does the script handle long requests?

Since the script relies on dynamic inclusion of the SCRIPT tags, all the data we upload to the server is generally a part of the SCRIPT url. Although, the specs impose no limit on the length of the GET request, all browsers do. The tests say we can be quite safe if the length of the SCRIPT url doesn’t exceed 2000 symbols. If the request is longer than 2000 symbols (the limit is configurable), the script splits the request into parts.

For instance, instead of doing this:

http://ajaxextended.com/api/? … a very-very long string that might break the browser…

we’re doing this:

http://ajaxextended.com/api/? … 1st part of this request …
http://ajaxextended.com/api/? … 2nd part of this request …

In the meantime, the server caches all the parts of the request. And when all the parts are received and assembled, the server backend finally performs the server-to-server request.

How does the server cache multipart requests?

If the request is too long, the client script splits the data into multiple parts that do not exceed the specified maximum length. When a server receives a part of the multipart request it writes the data into a cache file. The name of the cache file is the same as the unique ID of the request (yes, all requests have a unique ID). When all parts are received, the script removes the cache file and performs the server-to-server request.

What is the syntax of the response?

If you’ve ever heard of JSON, it’ll be really easy to understand how the response is constructed. Here is a real example of the reponse (getting the homempage of google.ru):

v35422275185316._parse({
'success': '1',
'responseHeaders': {
'Cache-Control': 'private',
'Content-Type': 'text/html',
'Content-Encoding': 'gzip',
'Server': 'GWS/2.1',
'Content-Length': '1852',
'Date': 'Mon, 06 Feb 2006 18:55:53 GMT',
'Connection': 'Keep-Alive'
},
'status': '200',
'statusText': 'OK',
'responseText': ' …the code of the page…‘
})

As you can see, all the data is encapsulated in curly brackets {}, that represent objects in JavaScript. Note, that both keys and values are quoted. v35422275185316 is the unique ID of the request. Here’s a brief description of the properties:

success
Possible values are 0, 1. Normally, it is 1. If an error occurs during the request, it is 0.
responseHeaders
HTTP headers received from the third-party server
status
HTTP status code (200, 404, etc.)
statusText
The text that describes the HTTP status code (’OK’, ‘Not found’, etc.)
responseText
The body of the reponse (quotes escaped)

If a fatal error occurs (the server script cannot connect to the specified website or it cannot create a cache file, or anything of the kind), the response will have only two properties:

v35422275185316._parse({
'success': '0',
'description': 'Cannot connect to www.unreachableserver.com'
})

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.