According to RFC 7231 § 3.1.1.5, 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. 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. This can cause unexpected behavior in clients that were written for the HHVM behavior.

We're not going to try to reimplement the HHVM behavior under PHP 7, but it could be useful to raise an explicit warning or error on a POST without a Content-Type header. A question is whether to do it as a warning or an error:

• The warning is friendlier for the current stage of the PHP 7 migration where it often does work, but is less visible to clients and has the chance of being so common as to overload logstash.
• The error will immediately break such clients rather than giving them some time to update their code.

I'm inclined to go with the warning to start with, with a patch prepared to turn off the logging to logstash in case the volume is more than anticipated.