Empty responseText from XMLHttpRequest

Question

I have written an XMLHttpRequest which runs fine but returns an empty responseText.

The javascript is as follows:

  var anUrl = "http://api.xxx.com/rates/csv/rates.txt";
  var myRequest = new XMLHttpRequest();

  callAjax(anUrl);

  function callAjax(url) {
     myRequest.open("GET", url, true);
     myRequest.onreadystatechange = responseAjax;
                 myRequest.setRequestHeader("Cache-Control", "no-cache");
     myRequest.send(null);
  }

  function responseAjax() {
     if(myRequest.readyState == 4) {
        if(myRequest.status == 200) {
            result = myRequest.responseText;
            alert(result);
            alert("we made it");
        } else {
            alert( " An error has occurred: " + myRequest.statusText);
        }
     }
  }

The code runs fine. I can walk through and I get the readyState == 4 and a status == 200 but the responseText is always blank.

I am getting a log error (in Safari debug) of Error dispatching: getProperties which I cannot seem to find reference to.

I have run the code in Safari and Firefox both locally and on a remote server.

The URL when put into a browser will return the string and give a status code of 200.

I wrote similar code to the same URL in a Mac Widget which runs fine, but the same code in a browser never returns a result.

Snubnosed

Something i have discovered which led to part of my initial confusion is that Safari has a modified security model that allows files running locally to access requests from any origin. This was done so that Dashboard Widgets cold access requests. So i initially wrote a widget, that would work, then when i didn't use Safari or from the local machine it wouldn't. However i have only just come across this tweak. – Snubnosed

Answer 1

Is http://api.xxx.com/ part of your domain? If not, you are being blocked by the same origin policy.

You may want to check out the following Stack Overflow post for a few possible workarounds:

• Ways to circumvent the same-origin policy

Loadstar

i had a feeling that might be it. The puzzling aspect of this is that in a Mac Widget i used the XMLHttpRequest to do the same thing and it works. I am assuming that in the widget's case i am not in a browser so not blocked. – Snubnosed

Actually this has nothing to do with xss, which is caused by failure to validate user input. Using XHR to access another domain is a violation of the Same Origin Policy: code.google.com/p/browsersec/wiki/Part2 – Libbi

@The Rook: Thanks for the note. Fixed my answer. – Loadstar

Answer 2

PROBLEM RESOLVED

In my case the problem was that I do the ajax call (with $.ajax, $.get or $.getJSON methods from jQuery) with full path in the url param:

url: "http://mydomain.com/site/cgi-bin/serverApp.php"

But the correct way is to pass the value of url as:

url: "site/cgi-bin/serverApp.php"

Some browser don't conflict and make no distiction between one text or another, but in Firefox 3.6 for Mac OS take this full path as "cross site scripting"... another thing, in the same browser there is a distinction between:

http://mydomain.com/site/index.html

And put

http://www.mydomain.com/site/index.html

In fact it is the correct point view, but most implementations make no distinction, so the solution was to remove all the text that specify the full path to the script in the methods that do the ajax request AND.... remove any BASE tag in the index.html file

base href="http://mydomain.com/" <--- bad idea, remove it!

If you don't remove it, this version of browser for this system may take your ajax request like if it is a cross site request!

I have the same problem but only on the Mac OS machine. The problem is that Firefox treat the ajax response as an "cross site" call, in any other machine/browser it works fine. I didn't found any help about this (I think that is a firefox implementation issue), but I'm going to prove the next code at the server side:

header('Content-type: application/json');

to ensure that browser get the data as "json data" ...

Usurp

Adding response header Content-Type: application/json worked for me. – Horsecar

Answer 3

The browser is preventing you from cross-site scripting.

If the url is outside of your domain, then you need to do this on the server side or move it into your domain.

Incubator

Answer 4

This might not be the best way to do it. But it somehow worked for me, so i'm going to run with it.

In my php function that returns the data, one line before the return line, I add an echo statement, echoing the data I want to send.

Now sure why it worked, but it did.

Flying

Answer 5

Had a similar problem to yours. What we had to do is use the document.domain solution found here:

Ways to circumvent the same-origin policy

We also needed to change thins on the web service side. Used the "Access-Control-Allow-Origin" header found here:

https://developer.mozilla.org/En/HTTP_access_control

Brazzaville