Crise.9401:

Are these supported by the api or do I have to write a server side wrapper for any cross-domain shenanigans for client side components.

poke.3712:

This is somewhat related to this topic. JSONP would work for me too.

vigorator.7420:

I agree a JSONP call back would be ideal for this. Make those clients do the work :P

poke.3712:

As per this answer JSONP won’t happen for now. CORS support is now there though.

Crise.9401:

As per this answer JSONP won’t happen for now. CORS support is now there though.

Replied there as well, but anything older than IE 10 does not deal with CORS very well… in particular if jQuery is used… and the fallback methods have some shortcomings.

I feel they are jumping the gun here with the obsolete consideration to be frank… especially considering that jsonp can relatively easily be opt in, and hardly requires any effort.

Pat Cavit.9234:

IE8+ does CORS fine, you’ll just need to use XDR instead of XHR for IE 8 & 9. We do it regularly & it works great.

JSONP is an elegant hack… but it’s still a hack.

Crise.9401:

IE8+ does CORS fine, you’ll just need to use XDR instead of XHR for IE 8 & 9. We do it regularly & it works great.

jQuery doesn’t support it, if I have to be aware of this… which I am painfully so, because jQuery refuses to adamantly support it and the plugins available to do it all have gotchas to be aware. That kinda defeats the point of using a javascript library that is intended to abstract the differences between vendors away.

To be honest, the only reason why I didn’t just drop it after Cliff’s statement is because jQuery just so happens to be one of the most popular javascript libraries on the market. If nothing more it is something that in my opinion deserves the benefit of a discussion.

As for XDR natively, here: http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

I would hardly call that wall of text of gotchas to be aware supporting CORS fine. Note that CORS XDR, according to above, fails to even address the http/https discussion where CORS was brought up to begin with.

For me personally it is a no brainer, wrapping the API’s server side takes about a minute, and I am being generous. But it does mask several end users of your API under a single requestee because the server is mediating the requests.

SpaceCowboy.1398:

I running into this issue now too. I’ve been trying to access the APIs with both jQuery and AngularJS. Both do not support MS XDR.

So, for the moment my web app can’t support IE8 or IE9!

I’m hosting my app via HTTP. Does anybody have a link to a good tutorial on how to get XDR working HTTP>HTTPS? Or is it not possible from a pure JavaScript solution?

Thanks!

Healix.5819:

It’s not possible to go from http to https when using XDR. You can either make your page https, simply tell the user to upgrade browsers or proxy the api yourself.

http://blogs.msdn.com/b/ieinternals/archive/2010/05/13/xdomainrequest-restrictions-limitations-and-workarounds.aspx

SpaceCowboy.1398:

I’m a noob when it comes to PHP, but by borrowing from other scripts and a little experimentation, I can pass this script a ‘url’ parameter and it will fetch the data for me.

I have a condition statement to only use this if the browser doesn’t support CORS via XHR.


	<?php

	$post_data = $HTTP_RAW_POST_DATA;

	$header[] = "Content-type: application/json";
	$header[] = "Content-length: " . strlen( $post_data );

	$ch = curl_init( $_GET[ "url" ] ); 
	curl_setopt( $ch, CURLOPT_RETURNTRANSFER, 1 );
	curl_setopt( $ch, CURLOPT_TIMEOUT, 10 );
	curl_setopt( $ch, CURLOPT_HTTPHEADER, $header );

	if ( strlen( $post_data ) > 0 ) {
		curl_setopt( $ch, CURLOPT_POST, 1 );
		curl_setopt( $ch, CURLOPT_POSTFIELDS, $post_data );
	}

	$response = curl_exec( $ch );

	if ( curl_errno( $ch ) ) {

		print curl_error( $ch );
		
	} else {

		curl_close( $ch );
		header( "Content-type: application/json" );
		print $response;
		
	}

	?>

I really hate Microsoft. :S
-Cowboy