#41349 [NEW]: $_POST not filled, altough raw POST is available
From: php at bitrockers dot de
Operating system: Linux Debian Etch
PHP version: 5.2.2
PHP Bug Type: HTTP related
Bug description: $_POST not filled, altough raw POST is available
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly, but
the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour. And
it's not easy to reproduce this bug ( because on most IE6 installations
everything works fine).
But I guess it's worth to take a look at the php-source, so that someone
may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit bug report at http://bugs.php.net/?id=41349edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41349r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41349r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41349r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41349r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41349r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41349r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41349r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41349r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41349r=support
Expected behavior:http://bugs.php.net/fix.php?id=41349r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41349r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41349r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41349r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41349r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41349r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41349r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41349r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41349r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41349r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41349r=mysqlcfg
#41349 [Fbk-Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
Reported By: php at bitrockers dot de
-Status: Feedback
+Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
Previous Comments:
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41349 [Opn]: Waiting for customers reponse...
ID: 41349
User updated by: php at bitrockers dot de
-Summary: $_POST not filled, altough raw POST is available
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
Previous Comments:
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41349 [Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
-Summary: Waiting for customers reponse...
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
(damn, destroyed the Summary) :)
Previous Comments:
[2007-05-10 15:27:13] php at bitrockers dot de
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41349 [Opn]: $_POST not filled, altough raw POST is available
ID: 41349
User updated by: php at bitrockers dot de
Reported By: php at bitrockers dot de
Status: Open
Bug Type: HTTP related
Operating System: Linux Debian Etch
PHP Version: 5.2.2
New Comment:
Could it be a problem that the POST request comes as post. Here an
excerpt of our logfile:
Customers (not working) request:
post /ajax/mypageProfileEdit/? HTTP/1.1 200 99
application/x-www-form-urlencoded; charset=utf-8 148
Request (my IE6, working):
POST /ajax/mypageProfileEdit/? HTTP/1.1 200 123
application/x-www-form-urlencoded; charset=utf-8 148
Does it make a difference for PHP if the POST request is lowercase?
Apache doesn't seem to have a problem with that. I don't know why the
customers IE6 sends XmlHttpRequest as lowercase post?
Previous Comments:
[2007-05-10 15:28:45] php at bitrockers dot de
(damn, destroyed the Summary) :)
[2007-05-10 15:27:13] php at bitrockers dot de
I've actually activated the logging of Content-Type and Content-Length.
Now I have to ask the customers, which are having the problems, to try
again.
As soon as I get the response, I will post the Content-Type of their
requests.
[2007-05-10 15:07:19] php at bitrockers dot de
The Content-Type is
application/x-www-form-urlencoded; charset=utf-8
At least that is the content-type from what I see when I do the request
in my browsers. Due to the fact that this problem occurs only at a few
IE6 installations I'm not absolutely sure that there is something on the
client-side which in some way modifies that header before sending it
to our server.
Is there a way to log the Content-Type of the request in PHP or apache,
to make sure that this is not the problem?
[2007-05-10 14:56:05] [EMAIL PROTECTED]
What is the content type of the request?
[2007-05-10 11:41:28] php at bitrockers dot de
Description:
Maybe this bug is related to Bugs 31417 and 41293. But I'm not sure,
because this bug occurs in 5.2.0 and 5.2.2.
The problem is:
When sending POST requests via the XmlHttpRequest active-x, on some IE6
installations this won't work properly. The POST request is successfully
sent to our webserver, and the raw http post data is filled correctly,
but the $_POST array is not filled with any information.
I can only guess that the error has something to do with some special
headers/encoding (Content-Length?) which is done by the
XmlHttpRequest-ActiveX on some IE6 installations.
And: Yes, I know that it's hard to find the reason for this behaviour.
And it's not easy to reproduce this bug ( because on most IE6
installations everything works fine).
But I guess it's worth to take a look at the php-source, so that
someone may get an idea which could cause this bug.
I'm trying to help you as much as possible. Unfortunately I cannot
reproduce the error by myself, so I have to ask the affected customers
each time we 'possibly' fixed the bug.
There must be a bug in php, because the raw-http request is filled
correctly (and we don't touch the $_POST var anywhere else in our code).
Reproduce code:
---
var_export($_POST);
$rawPost = file_get_contents('php://input');
echo \n$rawPost;
Expected result:
array('postVar1' = 'postValue1',
'postVar2' = 'postValue2')
postVar1=postValue1postVar2=postValue2
Actual result:
--
array()
postVar1=postValue1postVar2=postValue2
--
Edit this bug report at http://bugs.php.net/?id=41349edit=1
#41331 [NEW]: memory exhaustions after upgrading from 5.2.0 to 5.2.2
From: php at bitrockers dot de Operating system: Debian Etch 2.6.18-3-amd64 PHP version: 5.2.2 PHP Bug Type: Scripting Engine problem Bug description: memory exhaustions after upgrading from 5.2.0 to 5.2.2 Description: After upgrading from PHP 5.2.0 to 5.2.2 we've see a lot of PHP Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 1875 bytes) in ... erros in our error log. Before 5.2.0 we've had a memory limit of 8M, and we never faced that problem. After the problem occured we've increased the memory limit to 16M. Now the error shows up less frequently, but it's still there. I assume that there is some kind of memory leak in 5.2.2, or some function used in our scripts 'eats' a lot more memory than in 5.2.0. -- Edit bug report at http://bugs.php.net/?id=41331edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41331r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41331r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41331r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41331r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41331r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41331r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41331r=needscript Try newer version:http://bugs.php.net/fix.php?id=41331r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41331r=support Expected behavior:http://bugs.php.net/fix.php?id=41331r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41331r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41331r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41331r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41331r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41331r=dst IIS Stability:http://bugs.php.net/fix.php?id=41331r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41331r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41331r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41331r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41331r=mysqlcfg
