By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
444,136 Members | 2,135 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 444,136 IT Pros & Developers. It's quick & easy.

Synchronous Cross-Domain Request without Proxy

P: n/a
Hi All,

An experiment i'm doing requires requires a synchronous cross-domain
request, without using a proxy. I wondered if anyone had any ideas to
help me achieve this.

Below is what I have tried, including my conclusions/assumptions
(which i'll happily be corrected on if it solves my problem!):

The requirement not to use a proxy means I can't use the synchronous
mode of XMLHttpRequest, as it will not let me go cross-domain.

On-demand loading of javascript enables me to achieve the cross-domain
request by loading javascript of the form:

callback(data);

which on loading calls callback(), but it is not obvious how to make
this synchronous. I've also managed to get the same effect using a
hidden IFRAME, but again it relies on a callback. Is there a good way
to wrap/transform this in to a synchronous request?

The closest solution i've found which can probably solve it is the
narrative js (http://neilmix.com/narrativejs/doc/index.html), which
pre-processes javascript to turn a "yeild" function in to co-routines,
but this is getting a little scary/heavyweight!

Regardless of the actual implementation, the model i require is:

x = foo.bar();

where bar() returns a value based in part on the result of a cross-
domain request. i.e. the programmer doesn't care about the
implementation of bar(); it may be a standard method call, or may
include one or more cross-domain requests. The implementation details
must be hidden, hence at this level it appears as a normal blocking
call (i.e the solution is not "synchronous calls are evil, you should
be using asynchronous!").

Any ideas, pointers or suggestions would be very useful!

Thanks,
Simon

May 31 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Simon wrote:
Hi All,

An experiment i'm doing requires requires a synchronous cross-domain
request, without using a proxy. I wondered if anyone had any ideas to
help me achieve this.

Below is what I have tried, including my conclusions/assumptions
(which i'll happily be corrected on if it solves my problem!):

The requirement not to use a proxy means I can't use the synchronous
mode of XMLHttpRequest, as it will not let me go cross-domain.

On-demand loading of javascript enables me to achieve the cross-domain
request by loading javascript of the form:

callback(data);

which on loading calls callback(), but it is not obvious how to make
this synchronous. I've also managed to get the same effect using a
hidden IFRAME, but again it relies on a callback. Is there a good way
to wrap/transform this in to a synchronous request?

The closest solution i've found which can probably solve it is the
narrative js (http://neilmix.com/narrativejs/doc/index.html), which
pre-processes javascript to turn a "yeild" function in to co-routines,
but this is getting a little scary/heavyweight!

Regardless of the actual implementation, the model i require is:

x = foo.bar();

where bar() returns a value based in part on the result of a cross-
domain request. i.e. the programmer doesn't care about the
implementation of bar(); it may be a standard method call, or may
include one or more cross-domain requests. The implementation details
must be hidden, hence at this level it appears as a normal blocking
call (i.e the solution is not "synchronous calls are evil, you should
be using asynchronous!").

Any ideas, pointers or suggestions would be very useful!

Thanks,
Simon
Hi Simon,

Why don't you solve such issues serverside?
With PHP eg.
You can use AJAX if you want to call a PHP script on your own domain, let
that script fetch whatever it is you need, and return the result, formatted
as you like, to the browser?

I am maybe an oldfashioned guy, but use javascript for inside your browser
to manipulate stuff in there, and use a serverside solution when the need
arises.

I think you try to circumvent the cross-domain blocking.

Regards,
Erwin Moller
May 31 '07 #2

P: n/a
Hi Erwin,

Thanks for the reply.
Why don't you solve such issues serverside?
Because the browser/client can see both hosts, but the hosts can't see
each other. i.e. it is not possible to use one host as a proxy for
another.

I'm open to any ideas!

Simon

May 31 '07 #3

P: n/a
Simon wrote:
Hi Erwin,

Thanks for the reply.
>Why don't you solve such issues serverside?

Because the browser/client can see both hosts, but the hosts can't see
each other. i.e. it is not possible to use one host as a proxy for
another.
Hi Simon,

Are you sure the hosts cannot see each other?
If you want a javascript solution, the hosts must be reachable via http.
If they both have a http-server, you can (under most circumstances) do
something simple as:
$content = file("http://www.host1.com/something.html");

from php serverside.
That will fetch the full content of that page.

Are you sure the hosts cannot find each other but a browser can?

Regards,
Erwin Moller

>
I'm open to any ideas!

Simon
Jun 1 '07 #4

P: n/a
VK
On May 31, 1:09 pm, Simon <simon.a.f...@googlemail.comwrote:
The requirement not to use a proxy means I can't use the synchronous
mode of XMLHttpRequest, as it will not let me go cross-domain.
Not directly, because it would break cross-domain security. Still you
may use XHR combined with WSDL (Gecko) and WS (Microsoft) to use Web
services from different servers. WSDL (Web Service Description
Language) and WS (Web Services) are based on the same principles but
alas and as usual they are made to be as incompatible with each other
as possible, so a wrapper interface will be needed.
An OT note: same as in the VML - SVG case this is W3C only to blame
IMO, with their childish practice to take some long existing Microsoft
technology and then quickly write the same but with all words changed
and twisted around - so that would be always a standard and a non-
standard behavior of IE. This irritating practice seems going away
though.

Next you can use runtime <scriptblock insertion where the script
code would be generated by server and contain needed data in say JSON
format. This method is the most widely used and there is a number of
libraries to take care of different UA-specific issues.

For the last option you may use JSONet library for cross-domain data
exchange using CSS
http://jsnet.sourceforge.net/
Truly it never was in use on a corporate level. I merely made it as an
alternative to <scriptinsertion after I saw the US patent #6,941,562
development last year, so it was more of a message to the patent
holders: that Eolas-like community black lettering will not go. Yet
the library is fully operable and cross-UA tested.

Jun 2 '07 #5

P: n/a
Are you sure the hosts cannot see each other?
If you want a javascript solution, the hosts must be reachable via http.
If they both have a http-server, you can (under most circumstances) do
something simple as:
$content = file("http://www.host1.com/something.html");

from php serverside.
That will fetch the full content of that page.

Are you sure the hosts cannot find each other but a browser can?
Yeap, afraid so! Thanks anyway ;o)

Jun 4 '07 #6

P: n/a
Next you can use runtime <scriptblock insertion where the script
code would be generated by server and contain needed data in say JSON
format. This method is the most widely used and there is a number of
libraries to take care of different UA-specific issues.
This seems the best approach to use so far. Is there a way to wrap
this approach up in to what appears externally as synchronous call?

Jun 4 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.