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.

--
Bart

[Stevo]

Bart Van der Donck wrote:

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]

Stevo wrote:

Bart Van der Donck wrote:

>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.

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".

--
Bart

[VK]

On Dec 8, 9:23 pm, Bart Van der Donck <[e-mail]:

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.

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_rin...tes/index.html

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]

Bart Van der Donck wrote:

Stevo wrote:

>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

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]

VK wrote:

On Dec 8, 9:23 pm, Bart Van der Donck <[e-mail]:

>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.

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).

>>>http://www.geocities.com/schools_rin...tes/index.html

>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.

To be honest, I had that impression, yes :)

>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.

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

[Bart Van der Donck]

Stevo wrote:

Bart Van der Donck wrote:

> <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.

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.

--
Bart