php.net |  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
Votes:4
Avg. Score:4.5 ± 0.5
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
Have you experienced this issue?
Rate the importance of this bug to you:

 [2015-07-02 20:11 UTC] barry at yourang dot org
Description:
------------
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
var_dump($_POST);


PHP 5.5.24

$ curl http://viper-7.com/hOubxq/5.5.24/ --data 'key'
array(0) {
}

PHP 5.6.10

$ curl http://viper-7.com/h0PMyx/5.6.10/ --data 'key'
array(1) {
  ["key"]=>
  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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-07-02 20:42 UTC] requinix@php.net
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: http://git.php.net/?p=php-src.git;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" }' http://viper-7.com/h0PMyx/5.6.10/
array(1) {
  ["{_"key":_"value"_}"]=>
  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" }' http://viper-7.com/h0PMyx/5.6.10/
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] tyrael@php.net
-Type: Bug +Type: Documentation Problem -Package: Unknown/Other Function +Package: Documentation problem
 [2017-04-26 12:31 UTC] tyrael@php.net
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 https://twitter.com/_m6w6/status/856847613739618305 ) 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 http://php.net/manual/en/reserved.variables.post.php and on http://php.net/manual/en/migration56.new-features.php#migration56.new-features.reusable-input
 [2019-01-02 02:24 UTC] girgias@php.net
-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-2019 The PHP Group
All rights reserved.
Last updated: Wed Aug 21 22:01:26 2019 UTC