Despite the title, "Fixing AJAX: XmlHttpRequest Considered Harmful" addresses a potential gotcha with AJAX where the XmlHttpRequest has the same limitations of the applet sandbox, where the request can't go to a host other than the one that supplied the originating page. The author goes into three methods of circumventing this limitation, providing the mechanism for AJAX-enabled pages to call web services.

The question must be asked, though: is there a huge call for querying services like Google or Amazon via AJAX?

Ajax must stay in sandbox.. interactions with webservices
or remoting can be triggered by Ajax application but must be processed on serverside. If developers will choose to violate this principle then ajax stuff will be considered dangerous by users and browser creators and there will be more and more users with EcmaScript *simply disabled*.
Web developers tied with both hands in this case.

Before I knew about XmlHttpRequest, I used to do AJAX-like stuff in a hidden IFrame. The hidden IFrame can invoke Javascript (and thus perform DHTML actions) on the parent page, allowing AJAX-like behavior on some browsers that don't support XmlHttpRequest. If I understand these limitations correctly, I don't believe they would apply to a hidden IFrame. So, to circumvent this, couldn't one use a hidden IFrame?

I you probably still can. However, this loop hole could close in the future. I have in the passed used javascript to play sounds by writing an EMBED tag into an IFRAME. IE no longer allows this.

No, it should not work. You can't make cross-domain js calls.
See http://support.microsoft.com/default.aspx?scid=kb;en-us;167796
(Of course vulnerabilities may still exist...)

I ask myself the same question.
What is wrong in use hidden Iframe's.

The biggest showstopper is paranoya. MS IExporer historicaly has tendency to just disabling thing that is potentionally dangerous but they can't handle it in intelligent way (preventing rought aspects and allow useful). The users don't really knows that Iframes, XmlHttpRequest are really dangerous, but if browser warn them about it serveral times asking to disable *potentially* harmful feature than probably this feature will be disabled on client.
For example, if client click link that open new browser window via script, some browsers will consider that command to open window was issued in thread of handling user spawned event (e.g. onclick, ondblclick) and allow such action as action triggered by user (not allowing for exaple opening windows in window.onunload), while other browsers will just block all popup windows (no matter how it was triggered).
The choise for browser creator is obvious: provide smart and reliable sandbox or just disable all potential harmful thing. Thing like signing things and other security adhocs is not a practical case.

A hidden IFRAME can be used, but you are limited with what you can do with it. For example, if you use an IFRAME an duser used the back button, you will use the history of that IFRAME whereas the XmlHttpRequest will not. Also, you can post complex data with XmlHttpRequest very easily. With a hidden IFRAME, you'd end up having to replicate the form elements in the IFRAME. XmlHttpRequest also has some nice features like being able to issue a HEAD request to fetch just the mod date of a file on the server. I would use XmlHttpRequest over IFRAME any day of the week. But you'll never see me make a spread sheet in DHTML and AJAX over a nice Swing app :)

Before I knew about XmlHttpRequest, I used to do AJAX-like stuff in a hidden IFrame. The hidden IFrame can invoke Javascript (and thus perform DHTML actions) on the parent page, allowing AJAX-like behavior on some browsers that don't support XmlHttpRequest. If I understand these limitations correctly, I don't believe they would apply to a hidden IFrame. So, to circumvent this, couldn't one use a hidden IFrame?

IFrame's a bit tricky, because the parent *can* set an IFrame's source URL (src) to an external domain, but for security reasons, it *can't* proceed to interrogate the contents, even though the user can see them. Of course, with a rule like that, there are bound to be security flaws in some implementations, but it's definitely not a portable solution.

This AJAX mania is amusing me lately very much.
AJAX is nothing more then a small hack trying to correct much bigger hack (markup and document based applications over a statless connection).

I hope this madness will stop sooner then later and we will learn how to make client apps that are easy to install and upgrade, secure, with rich and responsive UI and are easy to develop and maintain.

Undoubtedly, it helps to write AJAX application if you generate AJAX stub from third-party WSDL directly. However, this solution is really not fixing AJAX and may not be sophisticated.

If AJAX is allowed to send XMLHttpRequest to third-party and your AJAX page are spreaded over the world, the third-party server may be suffered from high traffic attack from anonymous end user. Thus, all web browser disable it. If you write a proxy to route XMLHttpRequest to Third-party server, your application server will be firstly suffered instead of that third-party server. Thus, it is obvious that sandbox of XMLHttpRequest helps a lot on protection of the third-party server. Therefore, i think this article should call "Hacking AJAX" instead of "Fixing AJAX" as it really doens't fix AJAX bug.

Web service is really a kind of resource just like database. As a role of its client (i.e. application proxy in that article), you can not always route the request to client directly. You should take care of caching and pooling (e.g. pooling of google userid =P).

Please read:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp

http://codeproject.com/useritems/LeakPatterns.asp

One has really to think about using JavaScript for non-trivial stuff.

Due to incompatibility among browsers and buggy implementations, it is painful to do sophisticated operations, such as AJAX and DHTML, in JavaScript.

However, many tools emerged to soften the issue. It is better to count on one of them, rather than building from scratch.

We just announced an open source project called, ZK, to address the demand of rich user interfaces and easy to program. If you are interested, you might take a look at SourceForge. Thanks.