Page MenuHomePhabricator
Create Task
Maniphest T208191

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

Description

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 ( https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/306548/ ) 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.

Related Objects
Search...

Event Timeline

Bawolff created this task.Oct 29 2018, 7:30 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 29 2018, 7:30 AM
Bawolff added a parent task: T135963: Add support for Content-Security-Policy (CSP) headers in MediaWiki.Oct 29 2018, 7:52 AM

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.

jijiki added a subscriber: Joe.Oct 29 2018, 8:31 AM
• ema triaged this task as Medium priority.Oct 31 2018, 7:50 AM
Krinkle subscribed.Dec 26 2018, 6:39 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!

• Phabricator_maintenance moved this task from Backlog to Acknowledged on the SRE board.Jan 26 2019, 10:35 PM
Bawolff mentioned this in T28508: Content Security Policy (CSP).Mar 5 2019, 3:00 PM
Jdforrester-WMF subscribed.Jun 10 2019, 5:03 PM

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

Krinkle added a comment.EditedJun 10 2019, 6:38 PM
In T208191#5247496, @Jdforrester-WMF wrote:

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

Per:

In T208191#4843489, @Krinkle wrote:

[..] @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.

Jdforrester-WMF added a comment.Jun 10 2019, 6:40 PM

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

MaxSem closed this task as Declined.Oct 3 2019, 3:12 AM
MaxSem subscribed.

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

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits