Page MenuHomePhabricator

api.php PATH_INFO check infinite recursion
Closed, InvalidPublic

Description

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.

Event Timeline

Ofbeaton created this task.Tue, Feb 12, 3:48 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptTue, Feb 12, 3:48 AM
Anomie added a subscriber: Anomie.EditedTue, Feb 12, 2:41 PM

What exactly is the value of $_SERVER['PATH_INFO'] in your configuration, for a simple request like /w/api.php?action=query&list=allpages?

if I reintroduce fastcgi_param PATH_INFO $fastcgi_script_name; then when I call api.php my $_SERVER['PATH_INFO'] is /api.php

Anomie closed this task as Invalid.Tue, Feb 12, 3:10 PM

You're having problems because your webserver is misconfigured. PATH_INFO is supposed to be the part of the URL path component after the script name, it's not supposed to include the script name. See https://tools.ietf.org/html/rfc3875#section-4.1.5.

You might look at https://serverfault.com/questions/626552/php-fpm-nginx-giving-scripts-wrong-path-info. It seems you're supposed to configure it as fastcgi_param PATH_INFO $fastcgi_path_info;.

How frustrating. The problem I am trying to communicate is that the API PATH_INFO redirect shenanigans means that even a small misconfiguration on the server kills it. This is the only entry point that does this.

I'm not trying to say the server isn't misconfigured. I'm not asking for support on how to properly configure my server.

Just that mediawiki shouldn't do this weird redirect when it doesn't do it for any other entry point. Especially when it causes "invisible" problems that aren't easy to diagnose.

The reason for the "weird" redirect is T128209: Reflected File Download from api.php. Personally I'd have preferred an HTTP error, but others there wanted a redirect instead.