php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #41349 $_POST not filled, altough raw POST is available
Submitted: 2007-05-10 11:41 UTC Modified: 2007-05-10 22:17 UTC
From: php at bitrockers dot de Assigned:
Status: Not a bug Package: HTTP related
PHP Version: 5.2.2 OS: Linux Debian Etch
Private report: No CVE-ID: None
View Developer Edit
 [2007-05-10 11:41 UTC] 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=postValue1&postVar2=postValue2

Actual result:
--------------
array()

postVar1=postValue1&postVar2=postValue2

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-10 14:56 UTC] iliaa@php.net 
What is the content type of the request?
 [2007-05-10 15:07 UTC] 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 15:27 UTC] 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:28 UTC] php at bitrockers dot de 
(damn, destroyed the Summary) :)
 [2007-05-10 16:44 UTC] php at bitrockers dot de 
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"?
 [2007-05-10 20:23 UTC] tony2001@php.net 
From what I can see, it makes difference for Apache.
 [2007-05-10 21:58 UTC] php at bitrockers dot de 
Ok, so what's the difference for Apache? 

However... today I discovered that our javascript library calls the XmlHttpRequest with lowercase 'post', and because some weird reasons some IE6 installations doesn't translate that into uppercase 'POST'. 

So maybe it's not PHP to blame for this, but unfortunately there are a couple of javascript libraries which indeed use 'post' instead of POST (e.g.  mootools, prototype). 

There even were a post on the Webkit-mailinglist about that:
http://lists.macosforge.org/pipermail/webkit-unassigned/2006-March/006858.html

Therefore, if it's not too much work it would be a good idea to also populate the $_POST variable when the request is 'post'. 

Maybe that would save a lot of developers which rely on so popular javascript-frameworks like prototype or mootools a lot of headaches. 

In the end, of course, it's microsoft bug ( IE6 should have translated post to POST or at least throw an error about that).
 [2007-05-10 22:17 UTC] tony2001@php.net 
>Ok, so what's the difference for Apache? 
I can see it maintains a registry of methods in upper case.

>Maybe that would save a lot of developers 
Even if it's really can be worked around in PHP, you still would not be able to use it since it takes a lot of time for a new version to get installed on all servers on this planet.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 14:01:32 2024 UTC