|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #69982 Changed how $_POST is populated in PHP 5.6
Submitted: 2015-07-02 20:11 UTC Modified: 2019-01-02 02:24 UTC
Avg. Score:4.2 ± 0.7
Reproduced:3 of 4 (75.0%)
Same Version:1 (33.3%)
Same OS:3 (100.0%)
From: barry at yourang dot org Assigned:
Status: Verified Package: Documentation problem
PHP Version: 5.6 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: barry at yourang dot org
New email:
PHP Version: OS:


 [2015-07-02 20:11 UTC] barry at yourang dot org
Prior to PHP 5.6, POSTing "invalid" urlencoded data would result in $_POST being an empty array. In PHP 5.6, PHP now populates $_POST, which is unexpected.  This change seems backwards incompatible with previous versions of PHP and nothing is mentioned in the documentation that I can find. 

Test script:
Both of these URLs just do: 


PHP 5.5.24

$ curl --data 'key'
array(0) {

PHP 5.6.10

$ curl --data 'key'
array(1) {
  string(0) ""

Expected result:
I would expect the POST request to result in an empty $_POST array in 5.6 just like 5.5

Actual result:
$_POST is populated with data.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-02 20:42 UTC]
It changed during the implementation of slim_post_data for 5.6.0, but is this really the wrong behavior? It's the same way $_GET works...

Looks deliberate:;a=commitdiff;h=e6084da4735c945cb071c4d9259ea0d702eb77c6;hp=52ff129607a7193cccbc6bdfbf1c1e8586e8d0d2#patch15 (add_post_var explicitly allows "foo&" syntax while old php_std_post_handler code does not)
 [2015-07-03 02:50 UTC] barry at yourang dot org
I am not sure if the new behavior is correct or incorrect, but it's definitely different and seemingly not mentioned in the documentation. A more real-world example is POSTing JSON using the wrong Content-Type header (apparently clients do this).  In PHP <= 5.6.0 you would end up with an empty $_POST, now you have this: 

curl --data '{ "key": "value" }'
array(1) {
  string(0) ""

This is different than what you have if the correct "Content-Type: application/json" header is set in the request:

curl -H "Content-Type: application/json" --data '{ "key": "value" }'
array(0) {

In older versions of PHP you would end up with empty $_POST in either case.  I think I would consider this change a regression, but if it's determined that it was intentional, I think the docs should at least be updated to reflect the new behavior because it's backwards incompatible if you were expecting $_POST to be empty, etc.
 [2017-04-26 12:31 UTC]
-Type: Bug +Type: Documentation Problem -Package: Unknown/Other Function +Package: Documentation problem
 [2017-04-26 12:31 UTC]
While I don't like that this change slipped through undocumented but I have to agree with Damian and Michael(original author of the slim_post_data rfc/change ) and given how this is the only report about it and it is part of every currently currently supported php version we shouldn't change this behaviour.

I'm updating the issue to be a documentation problem, we should explicitly state this behaviour on and on
 [2019-01-02 02:24 UTC]
-Summary: PHP 5.6 populates $_POST with "invalid" data +Summary: Changed how $_POST is populated in PHP 5.6 -Status: Open +Status: Verified -Operating System: Linux +Operating System: -PHP Version: 5.6.10 +PHP Version: 5.6
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Wed Feb 21 03:01:33 2024 UTC