Wikimedia Bugzilla is closed!

There is most certainly logic in $.ajax to switch between xhr/json and script/jsonp. This has been in jQuery for many years.

The reason it isn't working might be related to the usage of protocol-relative urls, or the presence of CORS support.

To cite the relevant parts:

	// A cross-domain request is in order when url parts mismatch
	if ( s.crossDomain == null ) {
		parts = rurl.exec( s.url.toLowerCase() );
		s.crossDomain = !!( parts[ 1 ] !== ajaxLocParts[ 1 ] || .. );
	}
	..
	jQuery.ajaxTransport( "script", function(s) {
		// This transport only deals with cross domain requests
		if ( s.crossDomain ) {
			..
		}
	});
	..
	if ( xhrSupported ) { jQuery.ajaxTransport(function( s ) {
		if ( !s.crossDomain .. ) {
			return { send: function() {
				var xhr = s.xhr();
				..
	..

Anyway, no work around is needed. It is a well-known feature of $.ajax, we just need to start using it. And if it isn't working, find out what we're doing wrong on our end.

The crossDomain logic will switch between the 'script' and 'xhr' transports, but both requests will still have be JSONP and have the callback parameter.

See here: http://jsfiddle.net/yvzSL/228/

In your developer tools console you can see that the local request uses XHR, but it is still a JSONP request over XHR. I have read through the $.ajax docs a number of times now and I see no indication that it should behave otherwise.

I did some more re-thinking about this.

I examined the jQuery code and the 'crossDomain' attribute is just for selecting the transport (XMLHttpRequest or <script> tag). It does not select data types (json/jsonp), i.e. if the datatype is 'jsonp' and the request is local, you will get a 'jsonp' request with a 'callback' parameter over XMLHttpRequest. The MW core will assume that any request with a 'callback' parameter is from another domain, and will treat the request as unauthenticated.

MW core needs a better way to detect if a request is really cross-origin. The solution is CORS, but this is not supported in a standard way on IE9 (http://caniuse.com/cors). The most "correct" fix would be to change the MW core to use CORS to detect cross-origin requests, but this might break plugins relying on the API in IE<=9, so it would be a risky fix until IE9 is no longer a concern for anyone.

I'm now convinced that the simplest fix for now is to add some logic in the VisualEditor JS to detect if the request will be local, based on the target URL of the request. Then use the 'json' datatype if it is local, and the 'jsonp' datatype if not. Here is jQuery's logic for checking that: https://github.com/jquery/jquery/blob/master/src/ajax.js#L518

Note that I tried this out by implementing custom prefilters/transports for jQuery (to leverage the crossDomain code already present), but this approach is hacky and a dead end.

I ran into the same problem myself my private wiki (1.23 and the REL1_23 branch of VE)

What are the security implications if I make the workaround change mentioned above? I have a foreign API configured, but it's one I control.

Thanks!
--Ryan

(In reply to Barry Coughlan from comment #2)
> The crossDomain logic will switch between the 'script' and 'xhr' transports,
> but both requests will still have be JSONP and have the callback parameter.
> 
> See here: http://jsfiddle.net/yvzSL/228/
> 
> In your developer tools console you can see that the local request uses XHR,
> but it is still a JSONP request over XHR. I have read through the $.ajax
> docs a number of times now and I see no indication that it should behave
> otherwise.

You read wrong. &callback= (or rather s.jsonpCallback) is only applied when the "jsonp" transport is activated (builds on top of the "script" transport).

And the "json" dataType only activates "json" in case of crossDomain.

Making a plain api request to a non-crossdomain url does NOT result in a callback parameter. Instead it results in a plain JSON response that is parsed by JSON.parse, no callback or javascript execution comes into play.

MediaWiki core uses $.ajax in this in many places. For example mediawiki.user.js[1] uses it to fetch user rights and groups information from the API. This behaviour has been this way for quite a while.

Like I said, if VisualEditor and/or your wiki is doing it differently, there is most likely a bug in the code invoking $.ajax.


[1] https://github.com/wikimedia/mediawiki-core/blob/08c17086e1/resources/src/mediawiki/mediawiki.user.js#L27-L41

(In reply to Krinkle from comment #5)
> [callback] is only applied when the "jsonp" transport is activated (builds
> on top of the "script" transport).
> 
> And the "json" dataType only activates "json" in case of crossDomain.
> 

I mean, the "json" dataType only activates "jsonp" in case of crossDomain.

(In reply to Barry Coughlan from comment #2)
> The crossDomain logic will switch between the 'script' and 'xhr' transports,
> but both requests will still have be JSONP and have the callback parameter.
> 
> See here: http://jsfiddle.net/yvzSL/228/
> 
> In your developer tools console you can see that the local request uses XHR,
> but it is still a JSONP request over XHR. I have read through the $.ajax
> docs a number of times now and I see no indication that it should behave
> otherwise.

That example is broken. The first request is is malformed. "json jsonp" is not a valid dataType. This value is invalid and unsupported. It seems to default to a script tag instead, but as you can see the callback in that code never fires. Here's a forked version of that example where I added number "1" and "2". You'll find that "DONE 1" never appears.

http://jsfiddle.net/L5PtK/

(In reply to Krinkle from comment #7)
> (In reply to Barry Coughlan from comment #2)
> > The crossDomain logic will switch between the 'script' and 'xhr' transports,
> > but both requests will still have be JSONP and have the callback parameter.
> > 
> > See here: http://jsfiddle.net/yvzSL/228/
> > 
> > In your developer tools console you can see that the local request uses XHR,
> > but it is still a JSONP request over XHR. I have read through the $.ajax
> > docs a number of times now and I see no indication that it should behave
> > otherwise.
> 
> That example is broken. The first request is is malformed. "json jsonp" is
> not a valid dataType. This value is invalid and unsupported. It seems to
> default to a script tag instead, but as you can see the callback in that
> code never fires. Here's a forked version of that example where I added
> number "1" and "2". You'll find that "DONE 1" never appears.
> 
> http://jsfiddle.net/L5PtK/

To clarify, I know dataType supports multiple values, but that's for converting the response (e.g. xml over jsonp). But you can't convert the actual data from json to jsonp or from json to jsonp (unless an API would embed javascript inside json or something like that).

As for VisualEditor, it should use json when contacting the local API. and jsonp when contacting any foreign API (whether on the same domain or not).

There is logic for this in jQuery that automatically switches from "json" to "jsonp" for cross domain urls.

However that doesn't trigger the way I expected. It makes the assumption that 1) you should only make 'json' requests to APIs on the same domain or with CORS authentication set up. Then if a browser doesn't support CORS it will use script  with JSONP instead of XHR. So it functions like a fallback for browsers not supporting CORS, *not* as a convenience to switch to JSONP automatically for any cross domain url.

jquery.js
> if ( !options.crossDomain || support.cors ) {

*** Bug 68141 has been marked as a duplicate of this bug. ***

Change 150054 had a related patch set uploaded by Mooeypoo:
Switch between json/jsonp for local/remote api search

https://gerrit.wikimedia.org/r/150054

Change 150054 merged by jenkins-bot:
MWMediaSearchWidget: Use json/jsonp for local/foreign api respectively

https://gerrit.wikimedia.org/r/150054