According to RFC 7231 § 3.1.1.5,[1] a POST request that does not include a Content-Type header may be interpreted by the server in one of two ways:

1. It may assume application/octet-stream. In this case, PHP and the Action API will not see the request as having any parameters, and so will probably serve the auto-generated help page.[2] 2. It may "sniff" the content type. It's likely enough to correctly guess application/x-www-form-urlencoded in this case, and therefore PHP and the Action API will see the request as having the intended parameters.

It turns out that HHVM and PHP 7 (at least as used at Wikimedia) differ in their behaviors: PHP 7 seems to choose option 1, while HHVM chooses option 2.

Thus, clients that have been generating POST requests to Wikimedia wikis' Action APIs without a Content-Type header will have been receiving expected results from HHVM but will now start receiving unexpected results as Wikimedia's migration to PHP 7 proceeds.[3] Affected clients should be updated to include the Content-Type header in their requests.

See https://phabricator.wikimedia.org/T230526 for some details on this issue.

[1]: https://tools.ietf.org/html/rfc7231#section-3.1.1.5 [2]: As seen for example at https://www.mediawiki.org/w/api.php. [3]: See https://phabricator.wikimedia.org/T176370 for progress on the migration.