Page MenuHomePhabricator

API shouldn't warn about unrecognized parameter "_"
Closed, ResolvedPublic

Description

On some occasions jQuery adds a parameter &_=1234 to the URL to break caching. For calls to api.php this will return a warning about an unrecognized parameter. The API should just officially allow the "_" parameter for the porpoise of cache-breaking and should not show a warning about it.

Event Timeline

Schnark created this task.Mar 26 2015, 10:08 AM
Schnark updated the task description. (Show Details)
Schnark raised the priority of this task from to Needs Triage.
Schnark added a project: MediaWiki-API.
Schnark added a subscriber: Schnark.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 26 2015, 10:08 AM
Aklapper triaged this task as Low priority.Mar 26 2015, 1:44 PM
Anomie added a subscriber: Anomie.Mar 26 2015, 3:05 PM

The same effect could be gained by using the existing requestid parameter. Is there a good reason for such an obscurely-named parameter, e.g. does jQuery do this even when you don't ask it to?

jquery.ajax() has a parameter cache (see http://api.jquery.com/jquery.ajax/), which defaults to false for JSONP, and will add the _=1234. Of course this can be disabled (and is actually really stupid, because the callback function for JSONP varies with each request, breaking the cache anyway), but when you want to use jQuery's cache parameter, the _-URL-parameter will be used.

(and is actually really stupid, because the callback function for JSONP varies with each request, breaking the cache anyway)

Presumably it's because you might have specified 'jsonpCallback' to set a constant callback.

Since this only applies to jsonp (whether via 'jsonp' or 'script'), it's probably best to only ignore the bogus parameter in that situation.

Change 200174 had a related patch set uploaded (by Anomie):
API: Ignore '_' parameter in jsonp callback mode

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

Anomie claimed this task.Mar 27 2015, 4:40 PM
Anomie set Security to None.
Anomie moved this task from Needs details or plan to Needs Review on the MediaWiki-API board.

Change 200174 merged by jenkins-bot:
API: Ignore '_' parameter in jsonp callback mode

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

Umherirrender closed this task as Resolved.Aug 6 2015, 7:48 PM

(and is actually really stupid, because the callback function for JSONP varies with each request, breaking the cache anyway)

Presumably it's because you might have specified 'jsonpCallback' to set a constant callback.

No, it is not. It is because the jsonpCallback, while seemingly random by default, is not unique. They are re-used within a page context (not unlike how browser re-use connections from a pool).

And also because the cache option is independent from use of JSON-P. The majority of ajax requests do not use JSON-P, but cache should still result in predictable behaviour in such case.

While it's valid that MediaWiki probably shouldn't warn about _ for validity reasons (since we support use of jQuery), I'd say it's still very much useful to present a warning of sorts against this since people probably aren't bypassing cache on purpose.

Also, for 99% of use cases within the Wikimedia landscape, one doesn't have to use JSON-P at all. One can and should use plain ajax with JSON because we have CORS enabled. This allows requests to be cached between users of the same script that make the same request.

If you don't need to worry about old browsers not supporting CORS, use as follows:

$.ajax( {
  url: ...,
  dataType: 'json'
} ).then( function ( data ) {
 ..
} );

To support old browsers:

$.ajax( {
  url: ...,
  dataType: $.support.cors ? 'json' : 'jsonp',
  cache: true
} ).then( function ( data ) {
 ..
} );

Either way, for modern browser it'll make a cacheable request without any variation for JSON-P.