AJAX Cross Domain

[Bart Van der Donck]

Hello,

I'm presenting my new library 'AJAX Cross Domain' - a javascript
extension that allows to perform cross-domain AJAX requests.

http://www.ajax-cross-domain.com/

Any comments or suggestions are welcome.

 

[Stevo]

I'm presenting my new library 'AJAX Cross Domain' - a javascript
extension that allows to perform cross-domain AJAX requests.
http://www.ajax-cross-domain.com/
Any comments or suggestions are welcome.

Nicely done. Great job.

I was hoping it might enable me to do something I'd been wanting to do
for a while, but it looks like it doesn't. I'd like to know whether a
target link exists on another domain before I navigate to it. Kind of
like a 404-prevention. It seems like this would help if I was in control
of the target site, or had an active server page running somewhere, but
in a simple static html situation going to an external site with which I
have no affiliation, it looks like I'm still navigating blindly to it.

 

[Bart Van der Donck]

Nicely done. Great job.

Thanks. It took some effort, but I tried to make it as accessible as
possible for the user.

I was hoping it might enable me to do something I'd been wanting to do
for a while, but it looks like it doesn't. I'd like to know whether a
target link exists on another domain before I navigate to it. Kind of
like a 404-prevention. It seems like this would help if I was in control
of the target site, or had an active server page running somewhere, but
in a simple static html situation going to an external site with which I
have no affiliation, it looks like I'm still navigating blindly to it.

That should be no problem.

<script type="text/javascript"
src="/path/to/ACD.js?uri=(http://www.google.com)"></script>
<script type="text/javascript">
alert(ACD.status);
</script>

should give you '200 OK' if the remote resource "exists".

 

[VK]

Hello,

I'm presenting my new library 'AJAX Cross Domain' - a javascript
extension that allows to perform cross-domain AJAX requests.

http://www.ajax-cross-domain.com/

Any comments or suggestions are welcome.

Bart, first of all you did a great job by putting efforts both into
the script itself, the documentation and even the site layout.

Secondly, and in continuation of our discussion at
http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/7861e0c1b9a6fa1f
this is not AJAX and it is not cross-domain IMO. It is yet another
nicely done "pacified" content-grabber to be run server-side. There is
an N amount of such scripts written and X currently in use. Far not
all of them are used for content stealing, many are forcedly used by
server admins for the legitimate purpose as yours. A year or so ago I
also proposed in this group my StarGates PERL script as a temporary
workaround for the cross-browser lock:
http://www.geocities.com/schools_ring/stargates/index.html
An endless amount of such programs can be found in the Net starting
from the oldest PERL repository (after SPAN of course)
http://cgi.resourceindex.com/Programs_and_Scripts/Perl/Content_Retrieval/
Anyone can take any of them and use for AJAX instead of content
stealing.
I do remain on my point of view - no one has to share it - that this
traffic-doubling server-side solution is a dead branch of evolution.
It existence solely supported by the pointless stubbornness of all
browser producers first, and later by slow moving of alternate
producers who tried to avoid Web Service implementation as long as
possible.

Now the situation finally changed:
1) Gecko has its own implementation of Web Services over
WebServiceProxyFactory and server-side permissions file in XML format.
Alas and as it is often, all necessary steps has been carefully made
to make the whole construction as incompatible with long-existing
Microsoft model as possible - but what else new :-(
A common wrapper interface is clearly doable - as it was for AJAX
itself.
2) Finally we have a stable opposition of IE/FF with others have to
choose either side. It means that a solution covering both rivals - if
it gets popularity - means to everyone else to either follow one of
sides or to get out of market.

That leads to the necessity of a universal WebService library using
both Gecko and IE model - just like AJAX libraries do.
IMO

 

[Bart Van der Donck]

Bart, first of all you did a great job by putting efforts both into
the script itself, the documentation and even the site layout.

Thanks VK.

Secondly, and in continuation of our discussion this is not AJAX and
it is not cross-domain IMO.

My argument would be that it is AJAX because the ACD object is very
similar to the XMLHttpRequest object (ACD.responseText,
ACD.getAllResponseHeaders, ACD.getResponseHeader()...). The javascript
programmer has a hierarchy of objects available, and AJAX Cross Domain
adds just one to it, namely the ACD object. That's why I would prefer
the term 'extension' for it.

Probably you would rather call it a wrapper (which is basically how it
works indeed, see section 'Flowchart' in the docs) but that depends
from which point you look at it. The javascript programmer has his
usual DOM + one new object.

You state that it's not cross-domain. I can't think of a reason why it
would not be cross-domain because that's how it's intended to work.

It is yet another
nicely done "pacified" content-grabber to be run server-side. There is
an N amount of such scripts written and X currently in use. Far not
all of them are used for content stealing, many are forcedly used by
server admins for the legitimate purpose as yours. A year or so ago I
also proposed in this group my StarGates PERL script as a temporary
workaround for the cross-browser lock:
http://www.geocities.com/schools_ring/stargates/index.html

I was not aware of this program that you wrote. I see you use a number
of similar techniques as me, like putting the URL in query-string,
LWP, ... (by the way, you should really use 'strict' and 'warnings'
mode). But I think there is much more to it than the part you have
coded out. One thing which is not clear is how the authentication is
done. With no authentication anyone can request any resource from your
server under your name - just think how happy spammers would be with
that (when intended for admin tasks only, then authentication is
different of course).

In all modesty, I think I have taken it some steps further than you. I
believe my library could be suitable for public web sites and easy to
work with for javascript programmers.

An endless amount of such programs can be found in the Net starting
from the oldest PERL repository (after SPAN of course)

You probably mean CPAN ? Yes, I've been familiar with ResourceIndex
since the end of the nineties or so.

Anyone can take any of them and use for AJAX instead of content
stealing.
I do remain on my point of view - no one has to share it - that this
traffic-doubling server-side solution is a dead branch of evolution.
It existence solely supported by the pointless stubbornness of all
browser producers first, and later by slow moving of alternate
producers who tried to avoid Web Service implementation as long as
possible.

A good point is the dedoubling of traffic indeed. But one bridge too
far for me is concluding that such applications have no future.

Client side content-grabbers will never have the same possibilities
like server-side due to all kinds of (necessary) security measures.
That's why I believe AJAX Cross Domain could be a useful gateway to
provide in this functionality for the javascript programmer.

You're right that (of course) some of the techniques are (must be)
identical than the classic CGI-interfaces to mini-browsers. But as far
as I can see, none of them does it the AJAX-way, which is like
XMLHttpRequest works. Of course I'm fishing at the programmer here to
make him think "Hey! That's simple, I already know this, it's just
like XHR!". I consider this immediate Aha-Erlebnis as a big advantage
in user-friendliness and transparency for programmers.

 

[VK]

My argument would be that it is AJAX because the ACD object is very
similar to the XMLHttpRequest object (ACD.responseText,
ACD.getAllResponseHeaders, ACD.getResponseHeader()...). The javascript
programmer has a hierarchy of objects available, and AJAX Cross Domain
adds just one to it, namely the ACD object. That's why I would prefer
the term 'extension' for it.

Agreed. But in this case what ACD is as an "added value" item? It is
primarily and mainly a server-side script making request over virtual
browser to a 3rd party server and transferring response to client-
script. For IXMLHTTPRequest/XmlHttpRequest driven scripts client side
there is no any difference: they are issuing the same requests,
getting the same responses and have to work around the same bugs and
glitches as they used to. This way it would be IMHO much more user
friendly to make ACD as an extra wrapper over OPEN/SEND part of any
preexisting script. So whoever is using beloved/too-well-tested-to-
drop/contract implied AJAX library: they could use exactly the same
with just a few lines of wrapper for URL argument. By taking a known
library of the kind like say AjaxToolBox (http://www.ajaxtoolbox.com)
all what is really needed is to add extra logic to req.url assignment.
Block-code:
IF (URL is in SAME_DOMAIN)
DO_NOTHING
ELSE
URL = SAME_DOMAIN/ACD.cgi + URL

This way:
1) The changes are minimal and seamless
2) For same domain requests nothing changes at all
3) Server-side script is called only when it is really needed so for
cross-domain call.

I was not aware of this program that you wrote. I see you use a number
of similar techniques as me

Please, don't take it as some copyright implications from my side! I
have mentioned Star Gates only as a sample, and also to show that I
did something similar as well: it is easier to critique someone if you
show first a stuff of the same kind - but worser then yours of
course as I collected it over an hour and rather sloppy. Star Gates
was more of a mission statement as I was at that time upset on a
number of clueless Web articles about cross-domain security.

Client side content-grabbers will never have the same possibilities
like server-side due to all kinds of (necessary) security measures.
That's why I believe AJAX Cross Domain could be a useful gateway to
provide in this functionality for the javascript programmer.

Maybe they will never fide away and there will be always a legitimate
use for them.

Web Service is simply a completely different idea. It is basically ol'
good Java's RMI on new wheels. So instead of manual requests to the
same or different domains we are creating an object with methods run
client-side or server-side: depending on what is more useful. Like
say:
var trans = new Translator();
trans.checkInput(formValue); // client-side
trans.onready = callback;
trans.translate(formValue) // goes to server A
// or
trans.altTranslate(formValue) // goes to server B

 

[Stevo]

That should be no problem.
<script type="text/javascript"
src="/path/to/ACD.js?uri=(http://www.google.com)"></script>
should give you '200 OK' if the remote resource "exists".

But only if I have the CGI or PHP (or whatever it is) running on a
server. I need to do it with static files because I'm dealing with file
that are being served from a CDN (like Akamai) and they charge
significantly more if you want them to host active server pages.

 

[Bart Van der Donck]

Agreed. But in this case what ACD is as an "added value" item? It is
primarily and mainly a server-side script making request over virtual
browser to a 3rd party server and transferring response to client-
script.

The core mechanism lies at the server, yes. But only about 5% of the
code is actually performing the request itself; all the rest is 'AJAX-
ing' and wrapping it as complete package ready to use for within
javascript.

For IXMLHTTPRequest/XmlHttpRequest driven scripts client side
there is no any difference: they are issuing the same requests,
getting the same responses and have to work around the same bugs and
glitches as they used to. This way it would be IMHO much more user
friendly to make ACD as an extra wrapper over OPEN/SEND part of any
preexisting script. So whoever is using beloved/too-well-tested-to-
drop/contract implied AJAX library: they could use exactly the same
with just a few lines of wrapper for URL argument. By taking a known
library of the kind like say AjaxToolBox (http://www.ajaxtoolbox.com)
all what is really needed is to add extra logic to req.url assignment.
Block-code:
IF (URL is in SAME_DOMAIN)
DO_NOTHING
ELSE
URL = SAME_DOMAIN/ACD.cgi + URL

This way:
1) The changes are minimal and seamless
2) For same domain requests nothing changes at all
3) Server-side script is called only when it is really needed so for
cross-domain call.

I'ld say that normally a programmer would use XMLHttpRequest for same-
domain requests or his favourite library. But it's possible what you
describe; and any AJAX library is welcome to include AJAX Cross Domain
as well since it's free for everyone.

Though AJAX Cross Domain could be used for same-domain requests too;
that would be unwise since XMLHttpRequest does it directly to the
resource in question.

By the way, it's not ACD.cgi but ACD.js - allowing it to run as CGI
but output javascript code (small but important difference IMO).

Please, don't take it as some copyright implications from my side! I
have mentioned Star Gates only as a sample, and also to show that I
did something similar as well: it is easier to critique someone if you
show first a stuff of the same kind - but worser then yours of
course as I collected it over an hour and rather sloppy. Star Gates
was more of a mission statement as I was at that time upset on a
number of clueless Web articles about cross-domain security.

To be honest, I had that impression, yes

Maybe they will never fide away and there will be always a legitimate
use for them.

I tend to think in that direction, yes.

Web Service is simply a completely different idea. It is basically ol'
good Java's RMI on new wheels. So instead of manual requests to the
same or different domains we are creating an object with methods run
client-side or server-side: depending on what is more useful. Like
say:
var trans = new Translator();
trans.checkInput(formValue); // client-side
trans.onready = callback;
trans.translate(formValue) // goes to server A
// or
trans.altTranslate(formValue) // goes to server B

I don't know enough about Java or RMI to see this in the right
context.

 

[Bart Van der Donck]

Bart Van der Donck wrote:

But only if I have the CGI or PHP (or whatever it is) running on a
server.

Yes, the server must be configured to allow CGI scripts.

I need to do it with static files because I'm dealing with file
that are being served from a CDN (like Akamai) and they charge
significantly more if you want them to host active server pages.

I'm afraid AJAX Cross Domain cannot run then. One last try could be to
use Server Side Includes:

http://en.wikipedia.org/wiki/Server_Side_Includes

But I think it's not so likely that this would be supported with
already disabled PHP/CGI.