AJAX Cross Domain

Discussion in 'Javascript' started by Bart Van der Donck, Dec 8, 2007.

  1. 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
     
    Bart Van der Donck, Dec 8, 2007
    #1
    1. Advertising

  2. Bart Van der Donck

    Stevo Guest

    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.
     
    Stevo, Dec 8, 2007
    #2
    1. Advertising

  3. 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
     
    Bart Van der Donck, Dec 8, 2007
    #3
  4. Bart Van der Donck

    VK Guest

    On Dec 8, 5:44 pm, Bart Van der Donck <> wrote:
    > 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
     
    VK, Dec 8, 2007
    #4
  5. VK wrote:

    > On Dec 8, 5:44 pm, 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.

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

    --
    Bart
     
    Bart Van der Donck, Dec 8, 2007
    #5
  6. Bart Van der Donck

    VK Guest

    On Dec 8, 9:23 pm, Bart Van der Donck <> wrote:
    > 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_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


    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
     
    VK, Dec 8, 2007
    #6
  7. Bart Van der Donck

    Stevo Guest

    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.
     
    Stevo, Dec 9, 2007
    #7
  8. VK wrote:
    > On Dec 8, 9:23 pm, Bart Van der Donck <> wrote:
    >
    >> 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_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

    >
    > 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, Dec 9, 2007
    #8
  9. 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
     
    Bart Van der Donck, Dec 9, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. minnie
    Replies:
    1
    Views:
    757
    Andrew Thompson
    Dec 13, 2006
  2. Replies:
    12
    Views:
    243
  3. Adrian
    Replies:
    4
    Views:
    150
  4. Javier
    Replies:
    1
    Views:
    179
    Bart Van der Donck
    Aug 11, 2009
  5. Replies:
    5
    Views:
    255
    Thomas 'PointedEars' Lahn
    Nov 24, 2009
Loading...

Share This Page