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.
Does this mean that if a client doesn't set the Content-Type header, and it sends some parameters in the URI query string and some parameters in the HTTP request body, then the latter are now sometimes ignored (and eventually will always be ignored)?
If so, then this is a bit worrisome, in that safety-checks like starttimestamp=... and assertuser=1 wouldn't do their jobs, so actions might go through that aren't supposed to.
Is it possible for MediaWiki to detect that there was a message body but no Content-Type, and return an explicit error in that case?
Thanks, -Ran
On Fri, Aug 16, 2019, 12:07 PM Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
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:
- 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.
[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.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api-announce mailing list Mediawiki-api-announce@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce _______________________________________________ Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On Sat, Aug 17, 2019 at 2:38 AM Ran Ari-Gur ran.arigur@gmail.com wrote:
Does this mean that if a client doesn't set the Content-Type header, and it sends some parameters in the URI query string and some parameters in the HTTP request body, then the latter are now sometimes ignored (and eventually will always be ignored)?
Yes, it does.
If so, then this is a bit worrisome, in that safety-checks like starttimestamp=... and assertuser=1 wouldn't do their jobs, so actions might go through that aren't supposed to.
Since the "token" parameter is required to be in the POST body, the action should fail due to that being missing if the "action" parameter is in the query string.
Is it possible for MediaWiki to detect that there was a message body but no Content-Type, and return an explicit error in that case?
It should be possible to detect a POST with no Content-Type, that's a good idea. I doubt there's much point in trying to differentiate the rare case of a POST with an empty body, particularly since the client should still be including the content type even with that.
I filed https://phabricator.wikimedia.org/T230735 with the suggestion.
Since the "token" parameter is required to be in the POST body, the
action should fail due to that being missing if the "action" parameter is in the query string.
OK, phew, that's reassuring; thanks for the correction!
I filed https://phabricator.wikimedia.org/T230735 with the suggestion.
Looks good, thanks!
On Mon, Aug 19, 2019, 9:09 AM Brad Jorsch (Anomie) bjorsch@wikimedia.org wrote:
On Sat, Aug 17, 2019 at 2:38 AM Ran Ari-Gur ran.arigur@gmail.com wrote:
Does this mean that if a client doesn't set the Content-Type header, and it sends some parameters in the URI query string and some parameters in the HTTP request body, then the latter are now sometimes ignored (and eventually will always be ignored)?
Yes, it does.
If so, then this is a bit worrisome, in that safety-checks like starttimestamp=... and assertuser=1 wouldn't do their jobs, so actions might go through that aren't supposed to.
Since the "token" parameter is required to be in the POST body, the action should fail due to that being missing if the "action" parameter is in the query string.
Is it possible for MediaWiki to detect that there was a message body but no Content-Type, and return an explicit error in that case?
It should be possible to detect a POST with no Content-Type, that's a good idea. I doubt there's much point in trying to differentiate the rare case of a POST with an empty body, particularly since the client should still be including the content type even with that.
I filed https://phabricator.wikimedia.org/T230735 with the suggestion.
-- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation _______________________________________________ Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
mediawiki-api@lists.wikimedia.org