Skip to main content

QlikView Integrations

Discussion Board for collaboration on QlikView Integration.

Announcements
QlikWorld 2023, a live, in-person thrill ride. Save $300 before February 6: REGISTER NOW!
cancel
Showing results for 
Search instead for 
Did you mean: 
Not applicable

Error After Upgrade to IE 10 using xmlhttp


I had an extension that was working.  It called a web service to return data from a database.   Our company upgrade everyone to IE 10, and it stopped working.

I have reduced the extension to the bare minimum.  And tried doing xmlHTTP calls to different ones available on the web.

The basic code I'm using is:

xmlhttp=new XMLHttpRequest();

xmlhttp.open("GET",url,false); 

xmlhttp.send(null);

when the url is http://maps.googleapis.com/maps/api/elevation/xml?locations=39.7391536,-104.9847034|36.455556,-116.8...

or

http://iaspub.epa.gov/enviro/efservice/tri_facility/state_abbr/VA/rows/499:499

It works as expected

If the url is

http://services.faa.gov/airport/status/CLE.xml

or

http://www.broadbandmap.gov/broadbandmap/provider/name/alb?format=xml

It does not return any results.

I have tried both GET and POST along with asynchronous/synchronous .

This was also working when we had IE 8, but stopped when we upgraded to IE 10.   I'm running from my desktop in webview.

Attached is an extension with just the minimum code needed to recreate the problem.

The JavaScript has a variable called version you can set to run the different url's  version b and d will work.  version c and e will not.   version a is internal to our company so will not work regardless. 

If it displays text in the textbox it's working.

Anyone have any idea why. 

Is anyone doing XMLHttpRequest with IE 10, if so any issues? 

Thanks for any help.

1 Solution

Accepted Solutions
patrik_seger
Partner - Creator
Partner - Creator

Hi Steve

This problem seems to be related to cross-domain calls (run your example in a server and look at the console in Chrome to get good error messages). Some servers do not admit the request due to coming from another domain.

Using CORS

If the server side code set the flag "Access-Control-Allow-Origin: *" in the response header, then it works (eg look into the Response headers when using your option "d"). So if you have control over the server side, see to it that this flag is set.

In PHP that could look something like:

     header("Access-Control-Allow-Origin: *");

I should also add that setting this to "*" may compromise security (the reason why this problem occurs in the first place).

If your calls all come from the same domain, use that domain name instead of the star; "Access-Control-Allow-Origin: http://mydomain.com". If you have multiple domains that will send the request to the server, you may check every requests origin (compare with a list of approved domains) and set the header flag to a star for all approved domains and do not set this header flag at all for not approved domains.

Using JSONP

If the server does not set the flag like this, there may be an alternative way to get the data using JSONP. Eg the service services.faa.gov may reply in JSON format (changing URL to CLE?format=json in the end). Then you could use jQuery Ajax function to get the data. Paste this into your code and try it out:
     $.ajax({
         type: "GET",
         url: zurl,
         dataType: "jsonp",
         success: function (data) {

             // Pick your data from JSON struct instead of XML
             alert(JSON.stringify(data));
         },
         error: function (jqXHR, textStatus, errorThrown) {
             alert(errorThrown);
         }
     });

I tried it for your c and e examples, and it worked fine for c but not for e due to some problem in the returned JSON format from broadband.gov.

Please note that JSONP inserts the actual JSON data into the webpage showing QlikView so there are security concerns with JSONP as well. Also note that the jQuery used by QlikView may be of an older version than you expect so there may be issues around how certain jQuery functions work.

You could develop your own JSONP functionality to get better control over how it works, there are examples on the web how this is done.

For more background information, read more here, a good overview: http://en.wikipedia.org/wiki/Same_origin_policy

Why this worked in IE8, I do not know. It should behave in the same way as far as I know. I tried it out in IE9 and it behaved in the same way as IE10.

Updated:

So, to answer your question:

  1. If you have the possibilty to change the code of your internal server application, that should be the way forward.
  2. If not, there may be some setting in the web server running this application to always set the reply headers in a certain way. Eg, for Apache look here.
  3. If not possible, try and get the reply from your internal server in JSON format instead and use JSONP in your extension object.

Br Patrik

View solution in original post

6 Replies
Not applicable
Author

Hi,

     We've facing same lots issue with IE 10 which caused us to issuing notice to user to enabling "full time compatible mode" setting on IE10 to improve the compatibility issue.

     Hope it work for your case.

Regards,

Kho

patrik_seger
Partner - Creator
Partner - Creator

Hi Steve

This problem seems to be related to cross-domain calls (run your example in a server and look at the console in Chrome to get good error messages). Some servers do not admit the request due to coming from another domain.

Using CORS

If the server side code set the flag "Access-Control-Allow-Origin: *" in the response header, then it works (eg look into the Response headers when using your option "d"). So if you have control over the server side, see to it that this flag is set.

In PHP that could look something like:

     header("Access-Control-Allow-Origin: *");

I should also add that setting this to "*" may compromise security (the reason why this problem occurs in the first place).

If your calls all come from the same domain, use that domain name instead of the star; "Access-Control-Allow-Origin: http://mydomain.com". If you have multiple domains that will send the request to the server, you may check every requests origin (compare with a list of approved domains) and set the header flag to a star for all approved domains and do not set this header flag at all for not approved domains.

Using JSONP

If the server does not set the flag like this, there may be an alternative way to get the data using JSONP. Eg the service services.faa.gov may reply in JSON format (changing URL to CLE?format=json in the end). Then you could use jQuery Ajax function to get the data. Paste this into your code and try it out:
     $.ajax({
         type: "GET",
         url: zurl,
         dataType: "jsonp",
         success: function (data) {

             // Pick your data from JSON struct instead of XML
             alert(JSON.stringify(data));
         },
         error: function (jqXHR, textStatus, errorThrown) {
             alert(errorThrown);
         }
     });

I tried it for your c and e examples, and it worked fine for c but not for e due to some problem in the returned JSON format from broadband.gov.

Please note that JSONP inserts the actual JSON data into the webpage showing QlikView so there are security concerns with JSONP as well. Also note that the jQuery used by QlikView may be of an older version than you expect so there may be issues around how certain jQuery functions work.

You could develop your own JSONP functionality to get better control over how it works, there are examples on the web how this is done.

For more background information, read more here, a good overview: http://en.wikipedia.org/wiki/Same_origin_policy

Why this worked in IE8, I do not know. It should behave in the same way as far as I know. I tried it out in IE9 and it behaved in the same way as IE10.

Updated:

So, to answer your question:

  1. If you have the possibilty to change the code of your internal server application, that should be the way forward.
  2. If not, there may be some setting in the web server running this application to always set the reply headers in a certain way. Eg, for Apache look here.
  3. If not possible, try and get the reply from your internal server in JSON format instead and use JSONP in your extension object.

Br Patrik

Not applicable
Author

Thank you for your suggestion. 

I gave this a try, unfortunately it did not solve the problem.   But I do appreciate your feedback.  

Not applicable
Author

Thank you for the information.   I met with our WebMethods team this morning and they are looking into apply some of your suggestions.   I'll post the results in the near future.

Thanks

Clever_Anjos
Employee
Employee

As Jquery is embbed into QlikView now, I would rewrite your code using Jquery Ajax functions $.get, $.post and $ajax

jQuery.ajax() | jQuery API Documentation

Not applicable
Author


I still do not have a solution to this issue, but Patrik Seger's answer seems to be correct.  This is being cause by Cross Domain.

It looks like it can be handled from either the server side as outlined in Patrik's answer or from the Client side.

From the Client side:

Both IE 8 and IE 10 have a setting "Access Data Sources Across Domains" in both cases it is set to prompt.  However, IE 10 does not prompt.  If I set it to Disable it will then work.   However it is strongly recommended that you do not disable this setting.  And understandably my company would not allow it to be disabled in a production setting.

Thank you everyone for your comments.