Page MenuHomePhabricator

Set hhvm.virtual_host[default][always_decode_post_data] = false
Closed, DeclinedPublic


HHVM has a behaviour where it always treats the post body as decodable data even when the content-type is application/json or application/csp-report.

This is causing some CSP reports to be misinterpreted. Google suggests that setting hhvm.virtual_host[default][always_decode_post_data] = false fixes this issue.

Once upon a time I had a patch for this ( ) but I abandoned it as I don't think I really understood how our hhvm config is set. In any case, I'd appreciate if the config could be changed or someone can point me in the right direction on how to write a patch for this.

Event Timeline

For context, my specific issue is that The api dispatch code basically works by doing $foo = $_POST + $_GET; $action = $foo['action']; and from there deciding what module to invoke. In my case, the module is in a GET parameter. Sometimes the JSON POST body contains the string &action=something& (since often the JSON POST body contains urls), which will result in the wrong api action being executed.

ema triaged this task as Medium priority.Oct 31 2018, 7:50 AM

It seems that at P7727, @Joe confirms this bug with HHVM, confirms that PHP 7 does not have the bug; and... found that changing hhvm.server.always_decode_post_data=false does not make the bug go away.

Side note: I found this paste from Joe by searching for "always_decode_post_data" php on Google!

Does this have a PHP7 equivalent, given that we're moving off HHVM "soon"?

Does this have a PHP7 equivalent, given that we're moving off HHVM "soon"?


[..] @Joe confirms [..] that PHP 7 does not have the bug.

In a nut shell: While HHVM has a configuration option to break MediaWiki (on by default), PHP 7 has neither the option nor the bug. So, we're good.

Ah, so if we wait long enough, this will fix itself? ;-(

MaxSem subscribed.

Now that we're not supporting HHVM anymore, this is moot.