cross domain XHR

[Andrew Poulos]

If I want to send an XHR request to a different domain without expecting
a response is this possible? I've started looking into cross domain
security issues with AJAX and I'm unsure what gets restricted.

I'm building an elearning course that runs on one server and is to
notify a different server each time the course is completed.

Andrew Poulos

 

[Stor Ursa]

Because of Browser Security there is no way of sending a Request to a
server other than the one hosting the page. In IE there is a setting
to allow you to turn off that Security, but it would be a pain in the
butt to ask your user to go to Tools > Internet Options, and then
require all your user's to only use IE.

The best way I've found to do this is send a request to the server you
are hosting the page on, and let that server redirect the request to
the other server.

If you are using .NET take a look at the WebRequest class.
If you are using Java take a look at the URLConnection and
HttpURLConnection classes.
Other server-side languages should provide similar functionality.

 

[Bart Van der Donck]

If I want to send an XHR request to a different domain without expecting
a response is this possible? I've started looking into cross domain
security issues with AJAX and I'm unsure what gets restricted.

I'm building an elearning course that runs on one server and is to
notify a different server each time the course is completed.

It's not possible in a default javascript/AJAX environment. But there
are workarounds. You could try AJAX Cross Domain, a Perl/CGI approach:

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

 

[Jason S]

If I want to send an XHR request to a different domain without expecting
a response is this possible? I've started looking into cross domain
security issues with AJAX and I'm unsure what gets restricted.

I asked this question recently...
http://groups.google.com/group/mozilla.dev.ajax/browse_thread/thread/2c8290ae88e2065f

if you control both servers, then you could use the "Access-Control:"
header to grant cross-site permission, but it's kinda new & you need
browsers that pay attention to the use of this header. Firefox 3.0
doesn't but 3.1 is supposed to.

 

[Thomas 'PointedEars' Lahn]

If I want to send an XHR request to a different domain without expecting
a response is this possible?

Request to a non-existing server. Otherwise there is a response to a
request, be it only one with an error status code.

What you really wanted to ask is answered by

var o = new Image();
o.src = "http://foo.example/notify?foo=bar";

which is probably way more compatible than XHR.

I'm building an elearning course that runs on one server and is to
notify a different server each time the course is completed.

Another possibility is navigation in a hidden iframe.


PointedEars

 

[Bart Van der Donck]

Request to a non-existing server.  Otherwise there is a response to a
request, be it only one with an error status code.

What you really wanted to ask is answered by

  var o = new Image();
  o.src = "http://foo.example/notify?foo=bar";

which is probably way more compatible than XHR.

The wish of the original poster ('to notify a different server')
cannot be accomplished by XHR anyhow.

A few alternatives for your solution are a GET/POST-request (to/in
hidden iframe or not), an <img src=""> call, <script src="">, <object>/
<embed> etc. etc.

All these have one thing in common: once the request is fired,
javascript can't know what happens further to it, since the Same
Origin Policy applies:
http://en.wikipedia.org/wiki/Same_origin_policy
But given the further requirements of the original poster ('without
expecting a response'), I think this should be no problem.

 

[Jorge]

The wish of the original poster ('to notify a different server')
cannot be accomplished by XHR anyhow.

A few alternatives for your solution are a GET/POST-request (to/in
hidden iframe or not), an <img src=""> call, <script src="">, <object>/
<embed> etc. etc.

All these have one thing in common: once the request is fired,
javascript can't know what happens further to it, since the Same
Origin Policy applies:http://en.wikipedia.org/wiki/Same_origin_policy
But given the further requirements of the original poster ('without
expecting a response'), I think this should be no problem.

<script src="anotherDomain.com"></script> isn't subject to the SOP:
can be used to both send and receive data back...

 

[Bart Van der Donck]

<script src="anotherDomain.com"></script> isn't subject to the SOP:
can be used to both send and receive data back...

All javascript is subject to the SOP (by default). That is not
different with <script src="">; the requested javascript file has only
one environment that it can run in, namely in the webpage that had
requested it.

You're right that remote js-calls may be used to send/retrieve data,
but always in possible underlying mechanisms at the server (in this
case, the remote resource usually serves .js from an application). But
this stands apart from SOP since SOP applies to client scripting only.

 

[Jorge]

All javascript is subject to the SOP (by default). That is not
different with <script src="">; the requested javascript file has only
one environment that it can run in, namely in the webpage that had
requested it.

You're right that remote js-calls may be used to send/retrieve data,
but always in possible underlying mechanisms at the server (in this
case, the remote resource usually serves .js from an application). But
this stands apart from SOP since SOP applies to client scripting only.

A <script> tag coming from a completely different domain can access
freely and modify everything in the page, even though it's origin
isn't the same: it's not subject to the SOP:

http://jorgechamorro.com/cljs/026/

 

[Jorge]

All javascript is subject to the SOP (by default). That is not
different with <script src="">; the requested javascript file has only
one environment that it can run in, namely in the webpage that had
requested it.

You're right that remote js-calls may be used to send/retrieve data,
but always in possible underlying mechanisms at the server (in this
case, the remote resource usually serves .js from an application). But
this stands apart from SOP since SOP applies to client scripting only.

A <script> tag coming from a completely different domain can access
freely and modify everything in the page, even though its origin isn't
the same: it's not subject to the SOP:

http://jorgechamorro.com/cljs/026/