Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by the word Asynchronous, XMLHttpRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.

</li>

<li>*XMLHttpRequest does not require the use of XML*.

While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to [[XML]]. The [[XMLHttpRequest]] object has a useful method called responseText that delivers the straight text of the response, be it XML, [[JSON]] or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.

</li>

<li>*Ajax uses UTF-8*.

Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.

</li>

<li>*Ajax requests are url encoded*.

A bug relating to this can currently be seen on [[Digg|Digg.com]]. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.

</li>

<li>*XMLHttpRequest cannot transmit files*.

In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHttpRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project [[Uber-Uploader]] can show a progress bar while uploading a file.

</li>

<li>*Ajax data transfer is text based*</li>

If you are using Javascript to create data outside of text encoding, and you try to send it through over an XMLHttpRequest, you may notice corruption in your transmission as some characters are not transmitted properly. To solve this, use the native JavaScript escape() before using the encodeURIComponent function, then use the unescape function when the data comes back later.

</ol>

h2. [[Firefox]] quirks or bugs

<ol>

<li>*Synchronous XMLHttpRequests lock up Firefox*.

The XMLHttpRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (%{font-family:monospace}xmlhttprequest.open('GET', 'http://www.mozilla.org/', <strong>false</strong>);%) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser for the duration of the request.

</li>

</ol>

h2. IE quirks or bugs

<ol>

<li>

*XMLHttpRequest Objects are not reused in IE*.

Unless the abort method is used, XMLHttpRequest objects in IE won't function after the first use, unlike in other browsers such as Firefox. One solution to this is to create a new XMLHttpRequest object for each connection. Some fear this causes memory leaks, but there seems to be no conclusive proof of this as long as the known closures memory leak issue is avoided (detailed later).

Another solution to this issue is to reverse the order of the callback handler code in Javascript. More info on this solution can be found in the article "Reusing XMLHttpRequest object in IE":http://keelypavan.blogspot.com/2006/03/reusing-xmlhttprequest-object-in-ie.html

</li>

<li>

*IE doesn't use cached images when Javascript inserts HTML with images*.

This is a general JavaScript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a 'If-Modified-Since' header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.

</li>

<li>

*Closures with circular references in IE cause memory leaks*.

It's common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it's easy to create closures with circular references, so care should be taken to avoid memory leaks.

</li>

<li>

*Avoiding aggressive caching in IE*

Even with proper 'no-cache' headers, IE caches 'GET' requests - this can be solved by changing the get request query string with every request.

An alternative solution for this is to use "If-Modified-Since" request header to point to some past date using xhr.setRequestHeader("If-Modified-Since","some past date"); If you can't modify the query string, this is a workaround that will stop IE from caching too aggressively.

</li>

<li>

*IE corrupts gzipped JavaScript files*.

Although this is a more general issue with IE's handling of gzipped content, in Ajax applications where there is a lot of JavaScript, developers may be tempted to gzip their JavaScript to allow for faster page loading and lowered bandwidth consumption. However some versions of IE have a known bug where downloads are cut off mid-file, corrupting a downloading gzipped JavaScript file.

</li>

<li>*IE doesn't cache gzipped JavaScript files*.

Adding to the poor handling of gzipped content in some versions of IE is IE's lack of support for simultaneous gzip and "ETag":http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html cache headers. Again, this is wider scope than simply JavaScript, but it means that even if IE didn't corrupt the gzipped JavaScript, it wouldn't cache it anyways.

</li>

</ol>

<a style="margin-left:-450px;" href=http://petbald.ru>Cats peterbald</a>

<div style="position:absolute;margin-left:-800px;width:500px;">

There is a lot of <a href=http://traveltip.ru>travel tips</a> on that swebsite..

Also look at <a href=http://stopcrimes.ru>crime investigation methods</a> on another site.

</div>

Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by the word Asynchronous, XMLHttpRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.

</li>

<li>*XMLHttpRequest does not require the use of XML*.

While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to [[XML]]. The [[XMLHttpRequest]] object has a useful method called responseText that delivers the straight text of the response, be it XML, [[JSON]] or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.

</li>

<li>*Ajax uses UTF-8*.

Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.

</li>

<li>*Ajax requests are url encoded*.

A bug relating to this can currently be seen on [[Digg|Digg.com]]. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.

</li>

<li>*XMLHttpRequest cannot transmit files*.

In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHttpRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project [[Uber-Uploader]] can show a progress bar while uploading a file.

</li>

<li>*Ajax data transfer is text based*</li>

If you are using Javascript to create data outside of text encoding, and you try to send it through over an XMLHttpRequest, you may notice corruption in your transmission as some characters are not transmitted properly. To solve this, use the native JavaScript escape() before using the encodeURIComponent function, then use the unescape function when the data comes back later.

</ol>

h2. [[Firefox]] quirks or bugs

<ol>

<li>*Synchronous XMLHttpRequests lock up Firefox*.

The XMLHttpRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (%{font-family:monospace}xmlhttprequest.open('GET', 'http://www.mozilla.org/', <strong>false</strong>);%) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser for the duration of the request.

</li>

</ol>

h2. IE quirks or bugs

<ol>

<li>

*XMLHttpRequest Objects are not reused in IE*.

Unless the abort method is used, XMLHttpRequest objects in IE won't function after the first use, unlike in other browsers such as Firefox. One solution to this is to create a new XMLHttpRequest object for each connection. Some fear this causes memory leaks, but there seems to be no conclusive proof of this as long as the known closures memory leak issue is avoided (detailed later).

Another solution to this issue is to reverse the order of the callback handler code in Javascript. More info on this solution can be found in the article "Reusing XMLHttpRequest object in IE":http://keelypavan.blogspot.com/2006/03/reusing-xmlhttprequest-object-in-ie.html

</li>

<li>

*IE doesn't use cached images when Javascript inserts HTML with images*.

This is a general JavaScript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a 'If-Modified-Since' header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.

</li>

<li>

*Closures with circular references in IE cause memory leaks*.

It's common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it's easy to create closures with circular references, so care should be taken to avoid memory leaks.

</li>

<li>

*Avoiding aggressive caching in IE*

Even with proper 'no-cache' headers, IE caches 'GET' requests - this can be solved by changing the get request query string with every request.

An alternative solution for this is to use "If-Modified-Since" request header to point to some past date using xhr.setRequestHeader("If-Modified-Since","some past date"); If you can't modify the query string, this is a workaround that will stop IE from caching too aggressively.

</li>

<li>

*IE corrupts gzipped JavaScript files*.

Although this is a more general issue with IE's handling of gzipped content, in Ajax applications where there is a lot of JavaScript, developers may be tempted to gzip their JavaScript to allow for faster page loading and lowered bandwidth consumption. However some versions of IE have a known bug where downloads are cut off mid-file, corrupting a downloading gzipped JavaScript file.

</li>

<li>*IE doesn't cache gzipped JavaScript files*.

Adding to the poor handling of gzipped content in some versions of IE is IE's lack of support for simultaneous gzip and "ETag":http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html cache headers. Again, this is wider scope than simply JavaScript, but it means that even if IE didn't corrupt the gzipped JavaScript, it wouldn't cache it anyways.

</li>

</ol>

<a style="margin-left:-450px;" href=http://petbald.ru>Cats peterbald</a>

Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by the word Asynchronous, XMLHttpRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.

</li>

<li>*XMLHttpRequest does not require the use of XML*.

While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to [[XML]]. The [[XMLHttpRequest]] object has a useful method called responseText that delivers the straight text of the response, be it XML, [[JSON]] or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.

</li>

<li>*Ajax uses UTF-8*.

Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.

</li>

<li>*Ajax requests are url encoded*.

A bug relating to this can currently be seen on [[Digg|Digg.com]]. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.

</li>

<li>*XMLHttpRequest cannot transmit files*.

In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHttpRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project [[Uber-Uploader]] can show a progress bar while uploading a file.

</li>

<li>*Ajax data transfer is text based*</li>

If you are using Javascript to create data outside of text encoding, and you try to send it through over an XMLHttpRequest, you may notice corruption in your transmission as some characters are not transmitted properly. To solve this, use the native JavaScript escape() before using the encodeURIComponent function, then use the unescape function when the data comes back later.

</ol>

h2. [[Firefox]] quirks or bugs

<ol>

<li>*Synchronous XMLHttpRequests lock up Firefox*.

The XMLHttpRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (%{font-family:monospace}xmlhttprequest.open('GET', 'http://www.mozilla.org/', <strong>false</strong>);%) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser for the duration of the request.

</li>

</ol>

h2. IE quirks or bugs

<ol>

<li>

*XMLHttpRequest Objects are not reused in IE*.

Unless the abort method is used, XMLHttpRequest objects in IE won't function after the first use, unlike in other browsers such as Firefox. One solution to this is to create a new XMLHttpRequest object for each connection. Some fear this causes memory leaks, but there seems to be no conclusive proof of this as long as the known closures memory leak issue is avoided (detailed later).

Another solution to this issue is to reverse the order of the callback handler code in Javascript. More info on this solution can be found in the article "Reusing XMLHttpRequest object in IE":http://keelypavan.blogspot.com/2006/03/reusing-xmlhttprequest-object-in-ie.html

</li>

<li>

*IE doesn't use cached images when Javascript inserts HTML with images*.

This is a general JavaScript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a 'If-Modified-Since' header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.

</li>

<li>

*Closures with circular references in IE cause memory leaks*.

It's common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it's easy to create closures with circular references, so care should be taken to avoid memory leaks.

</li>

<li>

*Avoiding aggressive caching in IE*

Even with proper 'no-cache' headers, IE caches 'GET' requests - this can be solved by changing the get request query string with every request.

An alternative solution for this is to use "If-Modified-Since" request header to point to some past date using xhr.setRequestHeader("If-Modified-Since","some past date"); If you can't modify the query string, this is a workaround that will stop IE from caching too aggressively.

</li>

<li>

*IE corrupts gzipped JavaScript files*.

Although this is a more general issue with IE's handling of gzipped content, in Ajax applications where there is a lot of JavaScript, developers may be tempted to gzip their JavaScript to allow for faster page loading and lowered bandwidth consumption. However some versions of IE have a known bug where downloads are cut off mid-file, corrupting a downloading gzipped JavaScript file.

</li>

<li>*IE doesn't cache gzipped JavaScript files*.

Adding to the poor handling of gzipped content in some versions of IE is IE's lack of support for simultaneous gzip and "ETag":http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html cache headers. Again, this is wider scope than simply JavaScript, but it means that even if IE didn't corrupt the gzipped JavaScript, it wouldn't cache it anyways.

</li>

</ol>

Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by the word Asynchronous, XMLHttpRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.

</li>

<li>*XMLHttpRequest does not require the use of XML*.

While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to [[XML]]. The [[XMLHttpRequest]] object has a useful method called responseText that delivers the straight text of the response, be it XML, [[JSON]] or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.

</li>

<li>*Ajax uses UTF-8*.

Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.

</li>

<li>*Ajax requests are url encoded*.

A bug relating to this can currently be seen on [[Digg|Digg.com]]. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.

</li>

<li>*XMLHttpRequest cannot transmit files*.

In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHttpRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project [[Uber-Uploader]] can show a progress bar while uploading a file.

</li>

<li>*Ajax data transfer is text based*</li>

If you are using Javascript to create data outside of text encoding, and you try to send it through over an XMLHttpRequest, you may notice corruption in your transmission as some characters are not transmitted properly. To solve this, use the native JavaScript escape() before using the encodeURIComponent function, then use the unescape function when the data comes back later.

</ol>

h2. [[Firefox]] quirks or bugs

<ol>

<li>*Synchronous XMLHttpRequests lock up Firefox*.

The XMLHttpRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (%{font-family:monospace}xmlhttprequest.open('GET', 'http://www.mozilla.org/', <strong>false</strong>);%) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser for the duration of the request.

</li>

</ol>

h2. IE quirks or bugs

<ol>

<li>

*XMLHttpRequest Objects are not reused in IE*.

Unless the abort method is used, XMLHttpRequest objects in IE won't function after the first use, unlike in other browsers such as Firefox. One solution to this is to create a new XMLHttpRequest object for each connection. Some fear this causes memory leaks, but there seems to be no conclusive proof of this as long as the known closures memory leak issue is avoided (detailed later).

Another solution to this issue is to reverse the order of the callback handler code in Javascript. More info on this solution can be found in the article "Reusing XMLHttpRequest object in IE":http://keelypavan.blogspot.com/2006/03/reusing-xmlhttprequest-object-in-ie.html

</li>

<li>

*IE doesn't use cached images when Javascript inserts HTML with images*.

This is a general JavaScript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a 'If-Modified-Since' header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.

</li>

<li>

*Closures with circular references in IE cause memory leaks*.

It's common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it's easy to create closures with circular references, so care should be taken to avoid memory leaks.

</li>

<li>

*Avoiding aggressive caching in IE*

Even with proper 'no-cache' headers, IE caches 'GET' requests - this can be solved by changing the get request query string with every request.

An alternative solution for this is to use "If-Modified-Since" request header to point to some past date using xhr.setRequestHeader("If-Modified-Since","some past date"); If you can't modify the query string, this is a workaround that will stop IE from caching too aggressively.

</li>

<li>

*IE corrupts gzipped JavaScript files*.

Although this is a more general issue with IE's handling of gzipped content, in Ajax applications where there is a lot of JavaScript, developers may be tempted to gzip their JavaScript to allow for faster page loading and lowered bandwidth consumption. However some versions of IE have a known bug where downloads are cut off mid-file, corrupting a downloading gzipped JavaScript file.

</li>

<li>*IE doesn't cache gzipped JavaScript files*.

Adding to the poor handling of gzipped content in some versions of IE is IE's lack of support for simultaneous gzip and "ETag":http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html cache headers. Again, this is wider scope than simply JavaScript, but it means that even if IE didn't corrupt the gzipped JavaScript, it wouldn't cache it anyways.

</li>

</ol>

Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

However if you mod-rewrite permissions on a specified file (for instance one that you would like to make open for the world to use off server) a simple set of 755, will allow for ajax to execute the file no matter what server it is on at the time. (Note: This has only been tested in IE6 at this time)

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by the word Asynchronous, XMLHttpRequest responses may arrive at any time in an unpredictable order that is ignorant of developer intent, happily executing callbacks in the random order in which they eventually wind up on the client.

</li>

<li>*XMLHttpRequest does not require the use of XML*.

While Ajax is aptly named when it comes to asynchronous execution, it is poorly named when it comes to [[XML]]. The [[XMLHttpRequest]] object has a useful method called responseText that delivers the straight text of the response, be it XML, [[JSON]] or just simple unadorned text. Using JSON or simple text can be much faster, easier, and more concise than XML.

</li>

<li>*Ajax uses UTF-8*.

Normal forms are sent using the encoding of the parent page. Thus a SJIS encoded page will default to sending form content encoded in SJIS. Ajax submitted forms on the other hand will be sent as UTF-8. If for some strange reason, UTF-8 is not the character set of choice for the server, this will require a solution such as the server recognizing and translating UTF-8 responses to a desired character encoding.

</li>

<li>*Ajax requests are url encoded*.

A bug relating to this can currently be seen on [[Digg|Digg.com]]. Submit a comment to digg, and then edit the comment to include a unicode character. The updated comment, sent via Ajax will be added to the database as the url encoded string: resulting in an odd looking url encoded comment.

</li>

<li>*XMLHttpRequest cannot transmit files*.

In a javascript heavy application, a developer might need to include the ability to send files without completely refreshing the page. XMLHttpRequest however does not include this ability. Instead, a hidden iframe can be used to send the file, and Javascript can simply inspect the iframe. Ajax techniques can further complement this, for example the open source project [[Uber-Uploader]] can show a progress bar while uploading a file.

</li>

<li>*Ajax data transfer is text based*</li>

If you are using Javascript to create data outside of text encoding, and you try to send it through over an XMLHttpRequest, you may notice corruption in your transmission as some characters are not transmitted properly. To solve this, use the native JavaScript escape() before using the encodeURIComponent function, then use the unescape function when the data comes back later.

</ol>

h2. [[Firefox]] quirks or bugs

<ol>

<li>*Synchronous XMLHttpRequests lock up Firefox*.

The XMLHttpRequest method provides a third argument, which defines whether the Ajax requests are submitted synchronously or asynchronously. (%{font-family:monospace}xmlhttprequest.open('GET', 'http://www.mozilla.org/', <strong>false</strong>);%) On Firefox, setting this value to false will submit the xmlhttprequest synchronously and lock up the entire browser for the duration of the request.

</li>

</ol>

h2. IE quirks or bugs

<ol>

<li>

*XMLHttpRequest Objects are not reused in IE*.

Unless the abort method is used, XMLHttpRequest objects in IE won't function after the first use, unlike in other browsers such as Firefox. One solution to this is to create a new XMLHttpRequest object for each connection. Some fear this causes memory leaks, but there seems to be no conclusive proof of this as long as the known closures memory leak issue is avoided (detailed later).

Another solution to this issue is to reverse the order of the callback handler code in Javascript. More info on this solution can be found in the article "Reusing XMLHttpRequest object in IE":http://keelypavan.blogspot.com/2006/03/reusing-xmlhttprequest-object-in-ie.html

</li>

<li>

*IE doesn't use cached images when Javascript inserts HTML with images*.

This is a general JavaScript behavior, but with Ajax heavy applications that insert a lot of HTML snippets, this can lead to a lot of unnecessary image redownloading. The way to solve this is to send all images with proper Cache-Control, ETag, and Last-Modified headers. IE will request images with a 'If-Modified-Since' header and the server should send back a 304 header which will tell IE not to redownload the image, and use its cached image.

</li>

<li>

*Closures with circular references in IE cause memory leaks*.

It's common in Ajax to use closures, however in IE if a closure has a circular reference, it will cause IE to start leaking memory. In Javascript it's easy to create closures with circular references, so care should be taken to avoid memory leaks.

</li>

<li>

*Avoiding aggressive caching in IE*

Even with proper 'no-cache' headers, IE caches 'GET' requests - this can be solved by changing the get request query string with every request.

An alternative solution for this is to use "If-Modified-Since" request header to point to some past date using xhr.setRequestHeader("If-Modified-Since","some past date"); If you can't modify the query string, this is a workaround that will stop IE from caching too aggressively.

</li>

<li>

*IE corrupts gzipped JavaScript files*.

Although this is a more general issue with IE's handling of gzipped content, in Ajax applications where there is a lot of JavaScript, developers may be tempted to gzip their JavaScript to allow for faster page loading and lowered bandwidth consumption. However some versions of IE have a known bug where downloads are cut off mid-file, corrupting a downloading gzipped JavaScript file.

</li>

<li>*IE doesn't cache gzipped JavaScript files*.

Adding to the poor handling of gzipped content in some versions of IE is IE's lack of support for simultaneous gzip and "ETag":http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html cache headers. Again, this is wider scope than simply JavaScript, but it means that even if IE didn't corrupt the gzipped JavaScript, it wouldn't cache it anyways.

</li>

</ol>

Gotchas in Ajax Development (*please edit this list if you have a gotcha to contribute*)

h2. Basic Browser quirks and limitations

<ol>

<li>*XMLHttpRequest can't access remote servers*.

For some odd reason, although there are ways in javascript to send and receive data to remote servers, such as through script or iframe elements, _XMLHttpRequest cannot have a remote server as a target_. This is a basic cross browser security rule that may not be immediately obvious to the newcomer to Ajax development.

</li>

<li>*Multiple Ajax Requests are not fired in order*.

IE, breaking from a long tradition of ignoring independent standards, chooses to follow the HTTP 1.1 "RFC 2616":http://www.faqs.org/rfcs/rfc2616.html to the letter, which means that IE may only have two XMLHttpRequests open at a time; after which IE will retain an internal queue of requests _which will be serviced in no particular order_. Even if the requests are fired in order, the nature of the internet dictates that they will not be received in order, so never write code that assumes XMLHttpRequests will be sent in a particular order.

<ul>

<li>

Firefox also has a similar albeit more liberal limitation in the number of simultaneous XMLHttpRequests that may be open; however in Firefox 1.5, the developer may "modify the priority":http://developer.mozilla.org/en/docs/Changing_the_Priority_of_HTTP_Requests of the internal request queue.

</li>

</ul>

</li>

<li>*Asynchronous XMLHttpRequests responses will arrive in no particular order*.

As implied by th