MediaWiki 1.31 (verified 1.32 as well)
My nginx install had fastcgi_param PATH_INFO $fastcgi_script_name; in a configuration block for php-fpm.
So while my wiki worked fine with index.php, the API was broken, because of a forced redirect check resulted in infinite 301 redirects.
https://doc.wikimedia.org/mediawiki-core/master/php/api_8php_source.html
// PATH_INFO can be used for stupid things. We don't support it for api.php at // all, so error out if it's present. if ( isset( $_SERVER['PATH_INFO'] ) && $_SERVER['PATH_INFO'] != '' ) { $correctUrl = wfAppendQuery( wfScript( 'api' ), $wgRequest->getQueryValues() ); $correctUrl = wfExpandUrl( $correctUrl, PROTO_CANONICAL ); header( "Location: $correctUrl", true, 301 ); echo 'This endpoint does not support "path info", i.e. extra text between "api.php"' . 'and the "?". Remove any such text and try again.'; die( 1 ); }
This was a complete evening of puzzling troubleshooting to find the cause. In my case I was trying to use the Cargo extension, which kept behaving odly and failing to create tables. Eventually through dev tools I was able to figure out that it calls the API endpoints, which were then failing. From there I had to curl from the command line to get the error message, my browser (Edge) wasn't showing it. After that I had to read the code of the api.php file itself to figure out that PATH_INFO is just not allowed at all.
This seems silly. I am sure an argument can be made that the web server that was provided to me is not idealy configured, but given index.php works fine, api.php should also work. Some of us don't even always have control of the main nginx/php config.
At the very least there should be a setting we can set in LocalSettings.php to disable this behaviour.
Is this even detected in the mw-setup script to warn users that their API won't work?
I found a support ticket that seems to have other people (multiple) who ran into the same problem: https://www.mediawiki.org/wiki/Topic:U6pbdt5cevxjrxl6
Though unfortunately nobody responses with a correct answer for them.
None of the other entry points seem to have this smart redirect behaviour.