10 things IT needs to know about Ajax

The introduction of any new Web technology will affect a network's infrastructure in ways that range from inconsequential  to earth shattering. Ajax is one of the more disruptive new Web technologies traveling across networks today. To help you  minimize future surprises on your network, we've outlined the 10 things you should take to heart about Ajax. (Also see our slideshow illustrating tips for deploying Ajax applications effectively.)
1) Ajax is an idea, not an acronym
While Ajax commonly is spelled out as Asynchronous JavaScript and XML, the full name is not entirely appropriate because it oversimplifies  the history of the technology and the implementation options that lie at its heart. More exactly, Ajax encompasses the idea  that Web applications can be built to opt out of the typical post-wait-repeat cycle used in server-side-focused Web applications. Ajax lets Web applications move to a more responsive, continuous, but incremental style of  updating. Ajax provides users a richer, more interactive way of experiencing the underlying Web application. This goodness  for the user might mean that more monitoring and security oversight might be required of network professionals, as well as, potentially, server and network alterations.
2) It's really all about JavaScript
Ajax applications are written in JavaScript and usually rely on the XMLHttpRequest object for communications, which is making  its way through the World Wide Web Consortium process.Because, like many Web technologies, it now is only an ad hoc industrystandard, notable differences can be found in various browsers'implementations of it. It's also possible to use other data transportmechanisms — with and without widespread industry support — with Ajaxapplications, including traditional frame and image-cookie methods, aswell as the use of binary bridges to Flash or Java.
Regardless of the transport approach used by the developer, Ajax has raised JavaScript to a more important position within  a Web application than it previously held. JavaScript now is responsible for important data-collection, communication and  consumption duties, so it no longer can be treated as a second-class Web technology without serious repercussions.
Developers who think the JavaScript technology is toxic can try to avoid the language by having a tool or framework generate  it from some other language like Java (Google Web Toolkit, for example), or hide the code behind components or tags (such  as with .Net or Ruby). At the end of the day, however, JavaScript still will be in the application. It's better to understand  the language and embrace it directly, because if you are going to use Ajax, you ultimately are using lots of JavaScript.
Ajax is intertwined with the network, so bad code is going to meanlots of troubleshooting by network administrators, as well asdevelopers: The bottom line is to encourage good, network-aware coding!The same organizational "rules and tools" -- coding standards, testingregimes and source-code control — that are in place for other languagesmust be applied to JavaScript to ensure that Ajax applications aresupportable and robust.
3) XML is not required
Despite the "x" in the acronym, Ajax does not require XML. TheXMLHttpRequest object can transport any arbitrary text format. For manyAjax developers, JavaScript Object Notation or even raw JavaScript codefragments make more sense as a data format, given that JavaScript isthe consuming environment. For direct input into documents, otherdevelopers may favor raw text or HTML fragments. Still others will usesuch data formats as the less-known YAML markup language or such oldstandbys as comma-separated values.
Of course, it is possible and certainly reasonable to use XML, butit is far from required. Using binary formats for uploading files isnot supported yet by the XMLHttpRequest object, but considering thatFlash uses a binary format called Action Message Format, it is likelythat similar features will be found in Ajax applications soon enough.You should know which format is being passed around the network,because it isn't always XML. Also, make sure you can analyze the formatfor performance and security.
4) Plan for an increase in HTTP requests
The most obvious issue for the network administrator supporting Ajaxapplications is that the architectural programming pattern has changedthe network utilization of Web applications from a batch-like, somewhatinfrequent response of a few hundred kilobytes, to a more continuousexchange of smaller HTTP responses. This means that network-bound Weband application servers may find themselves even busier than before.What Ajax will do to your server and network utilization certainly willdepend on how the application is built — make sure your developersunderstand the network impact of their applications.

5) Optimize Ajax requests carefully
Web applications should adhere to the network delivery principle of sending less data, less often. That doesn't mean that  this principle is widely followed by developers, however. Fortunately for the network, HTTP compression of Ajax responses  can reduce response size and is supported in all modern browsers. Because of dynamic compression's overhead, however, speed  may not improve much if responses are indeed relatively small. This means that it would be wise for network administrators  to turn on compression on their Web server, but they need to understand that with Ajax applications, their gains won't be  as big as with traditional Web applications.
To send data less often, we generally would employ caching. MostAjax implementations can be openly hostile to caching, however, givencertain assumptions made by browsers regarding not re-fetching URLsduring the same session. Rather than work with caching, many Ajaxdevelopers will work aggressively to defeat caching via the headersetting or URL uniqueness.
It is possible to address caching concerns with a client-side Ajax cache written in JavaScript, but most Ajax libraries do  not implement such a feature. Network professionals should show developers the benefit of caching, because Ajax probably will  benefit more from that than from compression.
6) Acknowledge the two-connection limit
Ajax applications are limited by HTTP to two simultaneousconnections to the same URL. This is the way the HTTP protocol isdesigned, not some browser bug or limitation. The good news is that itkeeps many Ajax developers from swamping a server accidentally, thoughMicrosoft's Internet Explorer 8 is supposed to go well beyond thelimit. Chatty Ajax applications can be trouble, and with browserschanging the rules, network administrators need to keep a close eye onthe number of requests made, and work with application developers toavoid employing such design patterns as fast polling or long-heldconnections.
7) Watch out for response ordering
With traditional Web applications, the network effects of TCP/IP communications — such as the lack of order in which individual  HTTP responses are received — generally are not noticed by developers or users. The base unit, the HTML document, is received  before other objects, and it then triggers the request. Any subsequent request triggers a whole new base document, thereby  guaranteeing order. Ajax takes such implicit ordering away, however, so that an application dependent on proper sequencing  requires a response queue. Ajax frameworks, however, are not consistent in acknowledging this network concern. So, again,  make sure Ajax application developers understand such network-level concerns.
Acknowledge the effects of eliminating "Layer 8" error correction
For years, users have been correcting Web-delivery quality byreloading pages or pressing the Back button. Simply put, users doingthis help mitigate network problems because errors occur generally atexpected moments between page paints. With Ajax, however, applicationfailure is no longer that obvious. Worse yet, users often aremisinformed about errors, because the simple, animated-GIF spinningcircle provides little information about the true status of therequest.

Developers are at a loss because many libraries aren't effective at acknowledging that timeouts happen, retries must occur,  and server and data errors crop up. JavaScript diagnostics showing communication and code errors are rarely in place on the  client side, so blissful ignorance is the norm. More application-level monitoring is required for administrators to support  Ajax properly.
9) Old security threats get a second exposure
If you listen to the pundits, Ajax may appear to produce more attacksurface, but it really isn't any less secure than traditionalWeb-application development environments, because the HTTP inputs tothe trusted server side are the same — headers, query string andmessage body. If implicitly trusting client-side code and entered datais not verboten already in your Web development group, however, Ajaxmay push things in that direction.
Cross-site scripting (XSS) isn't a vulnerability new with Ajax; it is just more common, especially if an application allows  state data to be manipulated with JavaScript. HTML input should be disallowed in most cases, and HTTP Only Cookies should  be applied immediately to reduce cookie hijacking and other attacks via XSS.
Cross Site Request Forgery likewise isn't new with Ajax, but if your application developers aren't checking the HTTP Referer  (sic) header and managing sessions properly within Ajax applications, you've already been open to it, although it might be  worse now.
Hackers, like developers, now are more interested in using and abusing JavaScript, which increases the potential for exploits.  Network professionals should make sure developers are aware that client-side code can be manipulated even with obfuscation  in place, so data inputs should always be filtered and sanitized, Ajax or not.
10) Abide by same origin for your protection
On the positive side of security, JavaScript's same-origin policy(SOP) is fully enforced in an XMLHttpRequest-based Ajax application.This policy makes sure that scripts cannot talk to domains outside ofthose from which they are issued. From the developer's point of view,this can be quite annoying because it means that pages served, forexample, from ajaxref.com can't talk to a URL hosted onwww.ajaxref.com; even if it is the same machine, it isn't the sameexact domain. DNS equivalency doesn't matter here; it is a string-checkemployed by the SOP.
The SOP will severely hamper a developer's ability to perform someWeb-service efforts on the client side as well. Clearly the bestapproach is to use a proxy on the server to bounce requests to otherservers and combine the results. However, many Ajax developers attemptto break the same-origin restrictions. Using the <script> tag asa transport instead of the XMLHttpRequest object introduces dangeroustrust assumptions, and that leads to the origin of much of the concernabout overall Ajax security.
Now, with such browsers emerging as Firefox 3 and Internet Explorer8 employing native cross-domain request facilities, there is certain tobe more trouble on the horizon. As is the case with Java'ssecurity-sandbox concept, SOP restrictions are introduced just to keepdevelopers from destroying security. Go around such safeguards withextreme caution.
Watch what you wish for
With Ajax, rich-application widgets will win a project, but badplumbing may sink it. If the promise of a rich Ajax application isdelivered in a network environment that is occasionally fragile, userswill become disillusioned with the perceived instability of theapplication regardless of its slick interface. To enable desktop-likequality, network professionals must educate Ajax developers aboutcertain network and security fundamentals and provide a solid andconstantly monitored delivery platform that includes client-sidediagnostics on JavaScript functioning and network performance from theuser perspective. Users regularly see rich Web applications done right— like those coming from Google, for example — so anything less is arisky endeavor.