php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22427 Missing Form Post Data
Submitted: 2003-02-26 05:17 UTC Modified: 2013-02-18 00:04 UTC
Votes:224
Avg. Score:4.3 ± 1.0
Reproduced:185 of 192 (96.4%)
Same Version:44 (23.8%)
Same OS:68 (36.8%)
From: jroland at uow dot edu dot au Assigned:
Status: No Feedback Package: *General Issues
PHP Version: 4.2.3 OS: Windows XP / 2000
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: jroland at uow dot edu dot au
New email:
PHP Version: OS:

 

 [2003-02-26 05:17 UTC] jroland at uow dot edu dot au
I am currently experincing some problems with missing post form data. 

There seem two be 2 problems:
1) When a variable is long (for example a textarea and lots of text is in it), the post data is not sent.
2) Sometimes even with small textarea, the post is still not outputed, but if you hit refresh and click reload post data, it sometimes works. 

I have also set the max post size to 20MB which should be plenty for just text.

I seem to have this problems on all browsers / computers.

Ay ideas?

Thanks

Joel

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-03-11 10:15 UTC] s dot franke at bebbosoft dot de
I did not report that bug, but have the same problem. To be more specific:

I am using the command line version of PHP 4.2.3-Win32. But the problem still exists under php 4.3.0.
The bug (or misconfiguration?) is also reproducable with command line version of PHP4.2.3 under Linux.

When POST is used (in conjunction with multipart/form-data)the POST data is not read by PHP.

Writing an own funtion to read the POST data will let you read the POST data.

I could setup an URL to reproduce it and with a <? phpinfo(); ?> page to display how the variables are set. (I could also paste it here...)

regards

Stefan
 [2003-03-12 01:52 UTC] s dot franke at bebbosoft dot de
Additional info:

I am NOT using Apache. The used web server passes POST data untouched to the CGI (here the php executable).

regards

Stefan
 [2003-03-30 06:55 UTC] moriyoshi@php.net
I guess your problem is identical to bug #19460. Please confirm if httpd.conf is edited correctly.

 [2003-04-06 06:57 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 [2003-05-21 04:52 UTC] webmaster at dtshowtime dot lu dot eu dot org
I am experiencing the same problem under WinXP SP1, Apache 1.3.27, PHP 4.3.1 (installed as Apache Module). In my particular case I tried installing postnuke and got stuck an the license screen (a large textarea) which just won't get submitted using POST. I also experience intermittent POST failures when submitting smaller forms (like the first install screen which only asks to select a language).

What is the parameter in httpd.conf that should be checked? I would be glad to assist in getting rid of this as it is very annoying.
 [2003-06-05 08:20 UTC] webmaster at dtshowtime dot lu dot eu dot org
I can also reproduce this problem with PHP 4.3.2.
 [2003-12-27 20:28 UTC] ascj20 at dsl dot pipex dot net
On WinXP SP1 / Apache 1.3.27 / PHP 4.2.2(module) / testing locally with IE6 SP1

This bug has changed topic it seems, but on the original matter I have it too - tiny effective limits with $_POST and $_FILES.

By echoing getenv(CONTENT_LENGTH) I find a limit of 488 bytes from text-only form data (above which $_POST returns empty).  Using HTTP upload by POST the cutoff is about 2.5k for a gif file.  (Limit is higher when not using SSL but I guess that is to be expected?)

I hope this is a useful contribution to a bug that seems to be taxing a lot of folks.
 [2004-02-20 08:07 UTC] vincentfinet at hotmail dot com
Hi,

Don't know if it helps but I found out that informations about the file uploaded from a form using "multipart/form-data" like in the example below is not in the $_POST array but in the $_FILES array

<form enctype="multipart/form-data" method="post" action="WinnyReader.php">
  <input type="file" name="fWinnyFile" size="40" />
  <input type="submit" value="Go" />
</form>

After hitting the submit button, the second script (in my example, "WinnyReader.php") will look for informations about the file in $_FILES["fWinnyFile"] (and not in $_POST["fWinnyFile"] even if the method of the form is POST!!). 

That will do something like this:
if (isset($_FILES["fWinnyFile"]))
{
  $arWinnyFile = $_FILES["fWinnyFile"];
  echo "name : " . $arWinnyFile["name"] . "<br />\n";
  echo "type : " . $arWinnyFile["type"] . "<br />\n";
  echo "tmp_name : " . $arWinnyFile["tmp_name"] . "<br />\n";
  echo "error : " . $arWinnyFile["error"] . "<br />\n";
  echo "size : " . $arWinnyFile["size"] . "<br />\n";

  $stFilename = $arWinnyFile["tmp_name"];
}
else
{
  ...
}

Hope this helps!

Vincent FINET
 [2004-07-17 17:51 UTC] c dot neise at gmx dot de
I have also the first of these problems.

The script below reproduces the bug.

When entering a small amount of data, the data is displayed. 

With a large amount of data (e.g. a screen full of letters pasted into the text area) the data is lost.

I am using gentoo linux, php 4.3.8 and Apache 2.0.50.

If anything is missing please let me know.

Best regards,

Christian Neise.

<html>
<body>

<form method="POST">
<textarea name="test">
<?php echo $_POST['test']; ?>
</textarea>

<hr><input type="submit" name="dummy"><hr>

<pre>
<?php print_r($_POST); ?>
</pre>

</body>
</html>
 [2004-07-30 22:11 UTC] gary at garyslittlecompany dot com
I too am experiencing what has been described in the this submission.

I think I have isolated it to php on windows.  I summarize it thus because I have an xp, w2k3 and wme servers that experience the same problem.

Yes I have used the latest version as of today 4.3.9 build date 7/30/04.

I have scripts that have alot of post data, a table full of input objects, the table can be quite large.  If I exceed a certain amount (I know it is not an arbitrary size, but I don't know what the size is, but I can duplicate it).  Below are my scripts.

<?php
	print '<html><head></head><body><form name = "pageform" action = "post.php" method = "post"><table>';

	for ($l = 0; $l < 100; ++$l)
	{
		print "<tr><td>First Name</td><td><input type = \"text\", name = \"firstname[$l]\" /></td>\r\n";
		print "<td>Last Name</td><td><input type = \"text\", name = \"lastname[$l]\" /></td>\r\n";
		print "<td>City</td><td><input type = \"text\", name = \"city[$l]\" /></td>\r\n";
		print "<td>State</td><td><input type = \"text\", name = \"state[$l]\" /></td></tr>\r\n";
	}

	print '</table><input type = "submit" value = "submit"/></form></body></html>';
?>

This simply provides my form with a lot of input elements in my html.

When submitted it will call the following script

<?php
print getenv('CONTENT_LENGTH');
print "$HTTP_RAW_POST_DATA<br>";
print_r($_POST);
?>

Here is the output

6559
Array ( ) 



Now if I change my script (action = "cgi-bin\post.ext") to call the following c compiled script... 


#include <stdio.h>
#include <stdlib.h>
#include <string.h>
main()
   {
   char *endptr;
   int i;
   double contentlength;
   char buff[10000];
   char a,b;
   const char *len1 = getenv("CONTENT_LENGTH");
   contentlength=strtol(len1, &endptr, 10);
   fread(buff, contentlength, 1, stdin);
   printf("Content-type: text/html\n\n%s",buff);
   }


 to do the same thing essentially I will get the following

5B95%5D=&lastname%5B95%5D=&city%5B95%5D=&state%5B95%5D=&firstname%5B96%5D=&lastname%5B96%5D=&city%5B96%5D=&state%5B96%5D=&firstname%5B97%5D=&lastname%5B97%5D=&city%5B97%5D=&state%5B97%5D=&firstname%5B98%5D=&lastname%5B98%5D=&city%5B98%5D=&state%5B98%5D=&firstname%5B99%5D=&lastname%5B99%5D=&city%5B99%5D=&state%5B99%5D=

This is just a portion of the data that I get, it happens to be the last of the output do demonstrate that I do get the last of the input elements, notice city%5b99%5d, this is the 99th city element, the loop goes from 0-99.

Now if you reduce the loop to be 0-5 for example 
(for ($l = 0; $l < 5; ++$l)) I get the following output when I use the first script (action = "post.php").

309firstname%5B0%5D=&lastname%5B0%5D=&city%5B0%5D=&state%5B0%5D=&firstname%5B1%5D=&lastname%5B1%5D=&city%5B1%5D=&state%5B1%5D=&firstname%5B2%5D=&lastname%5B2%5D=&city%5B2%5D=&state%5B2%5D=&firstname%5B3%5D=&lastname%5B3%5D=&city%5B3%5D=&state%5B3%5D=&firstname%5B4%5D=&lastname%5B4%5D=&city%5B4%5D=&state%5B4%5D=
Array ( [firstname] => Array ( [0] => [1] => [2] => [3] => [4] => ) [lastname] => Array ( [0] => [1] => [2] => [3] => [4] => ) [city] => Array ( [0] => [1] => [2] => [3] => [4] => ) [state] => Array ( [0] => [1] => [2] => [3] => [4] => ) ) 

The first part is the raw post data, the last is the $_POST variable.

I did the c compiled script, simply to rule out my webserver (apache 1.3.27).
 [2004-08-02 13:51 UTC] admin at ensifex dot nl
After updating from 4.3.7 to 4.3.8 i'm loosing 
POST data. If i create a form with normal text fields and not to much input data there doesn't seem to be a problem. 

If i use <textarea> with a text larger 985 characters the post data is not send.

Used this script to test:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>
<head>
        <title>Untitled</title>
</head>

<body>
<form action="index.php" method="post">
<textarea name="text"></textarea>
<input type="submit"
</form>

<?
  print_r($_POST);
?>
</body>
</html>

if i add 'enctype="multipart/form-data"' to the form. All post data is send.

php version : 4.3.8
os: OpenBSD 3.5-current
apache: 1.3.29
 [2006-05-18 09:05 UTC] contact at ligh dot de
From my point of view, there seems to be a dependance between the appearance of this issue, and the webbrowser being used.

For example, I never had such an effect using Opera 8.54, but reliably could reproduce a missing of some first (and always 1 or 2 first) submitted fields (text, textarea, or files) when using Microsoft Internet Explorer 6.0 (XP SP2). 

I now started to circumvent this problem by adding two dummy hidden input fields which are expendable. Still, this issue needs further investigations, by adding different browsers into account.
 [2006-06-07 13:32 UTC] rossi at nelis dot fr
I confirm to you that i reproduce this problem with PHP5.

The first field (TextArea) is missing when i read $_POST with var_dump($_POST).

This bug exists only when i'm using Internet Explorer (6.0 for my version), not with Firefox 1.5.

I'm searching for a solution.
May be i have to create 2 dummy hidden fields :(:(

Please send me an email if you find the solution.
 [2006-08-11 15:43 UTC] gregory dot boyer at limbas dot com
we experience the same trouble as "rossi at nelis dot fr"
A form is send with POST method and with enctype multipart/form-data, in the target page the first field is missing. It is only occuring in IE6.0, and only with the enctype
 [2006-08-29 17:57 UTC] egil at egil dot net
I am also getting the exact same problem as "rossi at nelis 
dot fr" and "gregory dot boyer at limbas dot com". I am not 
able to reproduce this problem in other browsers than IE6 
posting using multipart/form-data as enctype.
 [2006-08-29 18:04 UTC] egil at egil dot net
Forgot to mention that I am having this problem with PHP 5.1.4 
running on FreeBSD and Apache 1.3.34.
 [2006-08-29 18:16 UTC] egil at egil dot net
Sorry for flooding this one, but I have noticed something else 
that I think is important here. I am not always getting this 
bug with IE6 either, it depends on the text I submit into one 
of my textarea or text fields. If one of them containts a 
double quotation mark of the type you get if you press shift-2 
within Word (not the standard double quotation mark, which 
works fine) and copy/paste the text into a textarea or 
textfield.

Please contact me if you need a better explaination and/or 
testdata.
 [2006-09-14 13:06 UTC] emil dot hall at gamereactor dot se
We must be talking about several different bugs here. But the bug where some fields are missing from $_POST is NOT a PHP bug, it's all Internet Explorer's fault. This HTML reproduces the bug in IE6:

<form method="post" action="whatever" enctype="multipart/form-data">
<input type="text" name="field1" value="1">
<input type="text" name="field2" value="2?">
<input type="checkbox" name="field3" value="3">
<input type="submit">
</form>

The weird character in the second input field will mess up IE's submit. Characters that confuse IE include:
three-dots-as-one-char ? aka chr(133)
the long dash ? aka chr(150)
and the double quotation mark ? aka chr(147)
All very common when you copy&paste from MS Word, just like Egil said. A packet sniffer reveals the broken POST request: (some irrelevant headers have been removed)

POST /whatever HTTP/1.1
Content-Type: multipart/form-data; boundary=---------------7d6399243401fe

field1"

1
---------------7d6399243401fe
Content-Disposition: form-data; name="field2"

2.
---------------7d6399243401fe--


Submit the same form with Firefox and the difference is obvious:


POST /whatever HTTP/1.1
Content-Type: multipart/form-data; boundary=------------------41184676334

------------------41184676334
Content-Disposition: form-data; name="field1"

1
------------------41184676334
Content-Disposition: form-data; name="field2"

2.
------------------41184676334--
 [2006-10-07 04:29 UTC] zero at tilt dot eu dot org
Same prob, PHP5 in cgi, Apache and env REQUEST_METHOD is POST, there is a content length, but $_POST is empty...

This is not a prob with my browser. Tested with Opera 9 and Firefox 1.5. And oh, no prob with an other server :/

Weird.
 [2006-10-18 08:15 UTC] thisisrobg at gmail dot com
Not sure if it exactly the same problem but POST related.
- PHP5.2.0RC6-dev
- Apache 2.2.3
- IE6

Code
<form name="processing" method="POST" action="sqlprocess.php">
SQL : <input type="text" name="sqlstring" /><br>
SQL2 : <input type="text" name="sqlstring2" /><br>
SQL3 : <input type="text" name="sqlstring3" />
<input type="submit" value="SUBMIT"/>
</form>

/*sqlprocess.php */
$query = $_REQUEST["sqlstring"];
$query2 = $_REQUEST["sqlstring2"];
$query3 = $_REQUEST["sqlstring3"];

print "Query: " . $query . "<br>";
print "Query2: " . $query2 . "<br>";
print "Query3: " . $query3 . "<br>";

---------

Problem: None of the field show up when request.

Experiments
1. Change form method to GET and it work perfectly.
2. Add/Remove fields make no different, still get nothing.
3. Change $_REQUEST to $_POST or $HTTP_POST_VARS make no different, still get nothing.
4. Change browser to Firefox 2.0b1 and it works fine.
5. Change browser to Opera 9.01 builds 8552 and it works fine.

Expecting the problem to be incompatibility between PHP5.2 and IE6.
I was using PHP5.1.6 and IIS and POST method works.
 [2006-12-07 22:30 UTC] celtic at sairyx dot org
I'm experiencing the same problem.

Server's running Apache 2 on a Windows Server 2003 machine.

IE 6.0, Windows XP SP 2, and about 90% of the time, POST data never reaches my PHP script.

Firefox 1.5 in the same conditions, and it runs perfectly.

It does seem suspiciously like an IE bug, but this seems too big to be a coincidence that IE never sends POST data to only these PHP applications.
 [2007-02-19 15:27 UTC] arek_felinczak at o2 dot pl
I had the same problem with empty $_POST table.
In my case solution was to remove post_max_size line from php.ini.
In php.ini i had 
post_max_size = 16000
instead of default post_max_size = 8M
 [2007-02-22 15:25 UTC] elio at tondo dot it
I am experiencing the same problem reported on 29 Aug 2006 by "egil at egil dot net". I can add some more details:

- I confirm that it happens only with IE;
- it is triggered when a character between 0x80 and 0x9f is used in a form field (e.g. the "Word" quotation marks, but also the Euro symbol) -- please note that these are the transposition in the "high half" part of extended ASCII of the 32 "control characters" of ASCII (0x00 - 0x1f);
- it has some relationship with character encoding;
- I can reproduce it on Linux with Apache 2 on Fedora 4 - 6 if I don't force "AddDefaultCharset UTF-8" in httpd.conf (the default in Fedora); with this directive the problem dies not happen, but the "strange" characters are interpreted incorrectly (because the file is not UTF8);
- I cannot reproduce it on Linux Mandrake 10 / Apache 2;
- I cannot reproduce it on Windows XP / XAMPP (Apache 2).

A further interesting detail: it happens only if the file containing the form has the .php extension; if it has the .htm extension it does not happen! (please note that I am using plain HTML for the form and some PHP to show the results).

From all of the above, it looks like it is not a PHP bug, but instead a IE6 bug that is triggered by some combination of MIME types and character encodings.

I am going to prepare a simpler test case (I am currently using a rather complicated page with a multi part form that I extracted from an application that was working on Mandrake and ceased to work on Fedora, and worked again by adding a dummy hidden field as the first one in the form...). When it will be ready I will post it here.

In the meantime, does anyone know if a similar problem has been reported elsewhere?
 [2007-03-12 19:53 UTC] jpsoren at gmail dot com
I experience this problem as well.
* Happens both with and without enctype set for form
* Happens in IE6 and IE7, NOT in Firefox 1.5/2
* Changing form to GET works flawlessly
* Input can range from a few text fields (1-6) or a mix of text fields and file fields, or just file fields (enctype set when file fields exist) and POST data will come up empty
* Often times hitting reload and selecting to resubmit the form data will have the POST data show up
* NO POST data will show up - I don't just lose some early fields

PHP 5.2.x (module), Apache 2.2.x, Windows XP SP2

This is a serious issue. Doesn't seem like anyone in this thread has found any sort of solution. Please post (or GET, ha) if you have any insight.
 [2007-04-07 14:12 UTC] linux at mccoull dot net
I have been having similar problems, i.e. a form which submits happily in Firefox, but not in IE 7. I have found this (very old!) forum entry - http://www.thescripts.com/forum/thread4451.html - which covers my issue, and I have implemented the solution by checking for (isset($_POST['submit']) || isset($_POST['submit_x'])) to check whether my submit button has been clicked. Note that is an underscore, not a '.'.

The solution works for GET method as well, if you are using that. If you submit a form with a 'submit' image button using GET, the browser URL shows submit.x=aa&submit.y=bb where aa and bb are the coordinates within the button image of where you clicked, but you should still check for $_GET['submit_x'] NOT $_GET['submit.x'].
 
As discussed in the above referred forum log this is an issue affecting Internet Explorer, Netscape and Opera, and maybe other browsers, and seems to be a simple failure to conform to the HTML standard for handling forms.

Hope this helps someone.

Andy
 [2007-05-10 09:15 UTC] tnieto at greenbit dot es
I have experienced this issue also.

My environment is:

- php 4.4.2 as a module
- Apache 1.3
- Windows 2000 Server

When I send a form with a text area using POST i don't receive any data.

In my case, it was because I was sending de form using a Javascript code:

		  function newitem(tipus)
		  {
			var accion;
			if (tipus == 1)
			{
			  accion = document.mailing.action="pre_mailingsmanuals.php";
			}
			else
			{
			  accion = document.mailing.action="env_mailingsmanuals.php";
			}
			document.mailing.action=accion;
			document.mailing.submit();
		  }		

The input was specified as a button: <input type="button" onclick="newitem(1) ...>" instead of as a submit.

Also, I was using a Rich Text Area. This issue doesn't occurs with a normal textarea.

The form get working when I change the "button" for a "submit", without use javascript code for send it.

I hope this message may be usefull for other users with the same problem. There is an official response from the PHP team from this issue ?

Regards
 [2007-06-12 21:29 UTC] relisys002 at yahoo dot com
Just came across the same problem myself last week.
PHP 5.1.6
Apache 2.0.59
FreeBSD 6.1-RELEASE-p11

EVERY browser I have tried in Windows fails to work past a request size of about 1450 bytes. I have tested IE 6.0, FF 2.0.0.3 and Safari Beta 3. PHP still returns the requests size via getenv("CONTENT_LENGTH") but both $_POST and $_GET are empty.

When I try the EXACT same page on the EXACT same server with both FF 2.0.0.3 and Safari 2.0.4(419.3) I have no problems submitting however much data I want. Here's my test form:

/-------- CODE ---------/

<html><head><title>TEST</title></head>
<body>
<pre>
<?php
print_r($_POST);
print_r($_GET);
echo "Request Length: ".getenv("CONTENT_LENGTH");
?>
</pre>
<form method="post" name="form" enctype="multipart/form-data" action="test.php">
<input type="file" name="file" /><br>
<input type="text" name="field" value="<?php echo $_POST['field']; ?>" /><br>
<textarea cols="80" rows="8" name="text"><?php echo $_POST['text']; ?></textarea><br>

<input type="image" name="submit" src="images/addcart.gif" /><br>
<input type="submit" name="submit-button" value="Real Submit Button" />
</form>
</body></html>

/-------- CODE ---------/

I get the same result with and without the enctype. I can't believe nobody has found a solution for this yet. If somebody has, please post it here or email me and I will.
 [2007-06-13 22:27 UTC] relisys002 at yahoo dot com
As a follow-up to my post yesterday, it appears as though the firewall software we have on our Windows machine (Comodo Firewall) was the cause of the problem. Using the Windows firewall didn't cause any problems. This may not be the case in for the other people with problems but I thought I would at least post the resolution to mine.

I would recommend that everyone disable all firewall and security software if they are experiencing this problem.
 [2007-07-04 06:05 UTC] ads at alex4all dot com
I just want to say Thanks a lot for comment called ([27 Mar 2003 2:08am UTC] sendoffer at ukr dot net); because my problem solved for same issue.

BR, Ali
 [2007-09-03 11:01 UTC] ben at hceo dot co dot uk
Hi,  

I found the same POST problem.  I have a login form and it works fine on FireFox and IE 6.0.3790, but not on IE 6.0.2800.  If the username and password are all one word it works fine on IE 6.0.2800 but if it is made of 2 or more words it only posts the variables once in every 10 or so posts.

I read that this problem can be got around by using .htm extension rather than .php - to get around this I changed the httpd.conf file to read:

AddType application/x-httpd-php .php .htm

I then changed the extension of my login file to .htm and this seems to work ok.
 [2007-09-13 20:49 UTC] lewisagosta at gmail dot com
I am still looking for why this worked... but...

When I changed "$_POST" to "$HTTP_POST_VARS", the form data is now there.  I think it has something to do with the global variables setting, but not sure yet.
 [2007-09-18 11:57 UTC] idefix at dwaal dot net
The same problem happens to me (and my users unfortunately).

- PHP Version 5.1.6
- Apache/2.2.3 (CentOS)
- only with enctype="multipart/form-data"
- only with IE6 on WinXP sp2
- _POST is completely empty (count($_POST) === 0)
- Uploaded files are smaller than 3 MB.
- Charset: US-ASCII (both Apache header and Meta-tag)

For some reason only _some_ IE6 WinXP SP2 machines trigger this error.

Opera and Firefox do not seem to trigger this error at all.
 [2007-09-21 08:48 UTC] umberto at meroni dot name
Hi there,
I solved this problem setting

output_buffering = On

in my PHP.ini.

I hope this helps.
Umberto Meroni
 [2007-10-02 06:08 UTC] solidus_in at yahoo dot com
When the post data contains HTML special entities i.e. "&amp;" it is stripped off. PHP POst variable only contains data before the first occurrence of "&amp;"

I am not sure whether it is a bug or something else. I am yet to test the POST containing other HTML entities. I have been trying to solve the issue but it remains yet.

Any help there?
 [2007-10-23 18:16 UTC] bcoy at chicagoreader dot com
This post exists to try and organize what I've read above.

There appear to be two main issues here.  The special character issue in IE seems to be well understood at this point.  The fix is to to translate all those characters into ascii (unicode html entities are helpful here).

However, it appears that several people, including myself, still have a length problem.  In my script, I have max_post_size set to 50M and output_buffering on (as suggested in these comments).  I have an all-ascii piece of data, which works up to 10021 characters, but fails at 10022, regardless of what the last character is.  This fails in all browsers: Safari, Firefox, and IE.  The data is not accessible via $_POST or $HTTP_POST_VARS.  It fails with or without enctype="multipart/form-data".  getenv("CONTENT_LENGTH") is 10173 in Firefox and 10111 in Safari.  If I change to a GET request, I receive an error indicating that the URI is too long for the server to support.

My setup is:
PHP 5.03
Apache 1.3.33
FreeBSD 4.10
 [2007-10-23 18:33 UTC] bcoy at chicagoreader dot com
It appears I miscounted the length of my data in the above comment.  Here is a test script that proves the maximum length, at least on this setup, is exactly 10,000 characters:

<html>
<body>

<p>
<?php
        echo "<strong>Request Length:</strong> " . getenv("CONTENT_LENGTH") . "<br />";   
        echo "<strong>POST:</strong> "; print_r($_POST); echo "<br />";   
        echo "<strong>HTTP_POST_VARS:</strong> "; print_r($HTTP_POST_VARS);   
?>
</p>

<form action="<?php echo $_SERVER['PHP_SELF']; ?>" method="post">

<textarea name="test" rows="50" cols="80"><?php
        for ($i = 0; $i < 10001; $i++) {
                echo 'a';
        }
?></textarea>

<input type="submit" />

</form>
</body>
</html>
 [2007-10-30 11:02 UTC] sbauer at gjl-network dot net
While experiencing this issue, too we found that the cause of this problem was the suhosin patch, wich was - by default - configured to have a max limit for the length of cookie, request, post, get and session vars. E.g. for POST this looks like:

suhosin.post.max_array_depth	100	100
suhosin.post.max_array_index_length	64	64
suhosin.post.max_name_length	64	64
suhosin.post.max_totalname_length	256	256
suhosin.post.max_value_length	65000	65000
suhosin.post.max_vars	200	200

Those derivatives needs to be set to a adequate higher number. E.g. in our case, the problem was, that our POST data was too long (as this seems to be the case for a lot of you here).

So I suggest to check your php.ini or (according to your distribution there often is a suhosin.ini) and correct the above values or set them to 0 to disable it. If those derivatives are not set, default values will be used.
You need to check / add:
suhosin.post.max_....
suhosin.request.max_...
suhosin.get.max_...
suhosin.session.max_...
suhosin.cookie.max_...

Refer to your phpinfo() where these values should be listed!
 [2008-02-07 14:41 UTC] multiplexor at hotmail dot com
All, I'm having the same problem but useing struts/apache java combo...

i noticed during the post, i was missing data. To resolve the issue, i finally found out that I had to right click on my web page and set the encoding to UTF-8. I resubmitted and it worked properly....

hopefully this helps others out there with the same issue...
 [2008-02-12 08:10 UTC] derrickpereira at gmail dot com
Had this same issue where form fields would NOT get passed if I was using IE6, but went through without issues on Firefox. Using $_POST, $_GET I would get nothing...

I traced the problem to the name I had given to textfield inputs - 

<input name="height" type="text">
<input name="length" type="text">

Changed them to m_height and m_length respectively and the form passed without issues. Perhaps there are some reserved keywords that you cannot use as name in IE6?

Hope that helps.

Derrick
 [2008-07-21 11:19 UTC] americo dot patetta at gmail dot com
CONFIRMATION: The bug is present even using PHP 5.x and Apache 2.x ON WINDOWS; It only shows up when posting from IE an using multipart/data. Firefox works just fine.
 [2008-11-13 16:58 UTC] keith at tdrnetworks dot com
Regarding the enctype="multipart/form-data" not populating the $_POST vars I found my solution was to disable the Suhosin security module.

Have a go!
 [2009-02-05 18:49 UTC] neal dot pressley at yahoo dot com
I was facing the same problem. I had a html form with php scripts in which I was submitting radio buttons or checkboxes. When I post the form, PHP was not finding any post parameters. it was random, some time it was working and some time not. Even I tried with Get, it worked some time and some time not.  Then I change ENCTYPE from uppercase to lowercase and it started working prefectly
<form enctype="multipart/form-data" action="ManageMapping.php" method="POST">
 [2009-02-05 23:38 UTC] neal dot pressley at yahoo dot com
Please ignore the above comments. changing the case did not fix the problem. Its just irratic. it works some time, it does not work some time. The problem with both post and get. I have a checkbox and submit button in the form. If I do not check the checkbox and just submit the button, it works but if I use check and enter submit, it does not work.

I moved the related part of the code from the big php file and tried to isolate the problem. Surprisingly it works perfectly as a small file but in the big php which has few more forms and tables, it does not work.
=====
<?php
	echo "<pre>";
	echo "post is";
	print_r($_POST);
	echo "get is";
	print_r($_GET);
			echo "request is";
	print_r($_REQUEST);
	echo "let us check HTTP_POST_VARS";
	print_r($HTTP_POST_VARS);
	echo "</pre>";



?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<link rel="stylesheet" type="text/css" media="all" href="../../stylesheet.css">
<title>Managing URL to StartContext Mapping </title>
</head>

<body style="margin: 0px;" onLoad="preloader();">


<form enctype="multipart/form-data" action="test1.php" method="POST">
<input type="hidden" name="submitted" value="true">

<input type="checkbox" name="dboptions" class="radio">Delete existing mappings from the database before loading the data from the CSV File.
<input type="submit" name="submit" class="buttons" value="submit">
</form> 


</body>
</html>
===============
 [2009-11-03 07:57 UTC] medhat dot s at scs-net dot org
I have the same problem!
sometimes, all post variables disappear although that I use a normal form with normal text inputs & normal data size. no textareas and no "multiform" tag in the form
php version : 5.1.6 apache webserver on Linux server.

I'm still unable to fix it!
 [2010-01-27 19:50 UTC] pierre at greywacke dot co dot za
I am also experiencing loss of form fields, albeit randomly. is there not a function to reload/refresh the data, i'm sure i've seen one albeit deprecated.
 [2010-01-27 20:44 UTC] pierre at greywacke dot co dot za
hi, i forgot to add the form submitted. i believe this could be in ie, but why? how can i prevent this from happening?
<form name="contact" method="POST" action="action.php" enctype="multipart/form-data" id="contact" onSubmit="return Validatecontact(this);">
using php 5.2.9 - believe the problem to be client browser side as reported in other comments.
 [2010-02-03 10:22 UTC] lars at renoz dot dk
Same problem here - $_POST is randomly incomplete or empty.

I have only seen this with IE - from version 6 to 8.

tcpdump shows a bit more of the story:

user sends:
POST /bla.php?id=bla
...
Content-Length: 80

but there is no data in that packet.

A bit later Apache reaches timeout, and closes the connection. At this point it send a 503 error to the user, but executes PHP with the incomplete post.

After the user received the 503 error - the browser actually sends a packet with the missing post data. Strange and clearly a browser bug. It should be noted that the post is so small that there is plenty of room in the first packet.

Now - the strange part is - why is PHP being executed? And why is PHP allowing it self to be executed. Content-Length is clearly invalid, and the conntection is closed (and PHP is setup to ignore aborted requests (ignore_user_abort is off).
 [2010-07-07 10:47 UTC] kernelu at gmail dot com
Had the same problem (the submited data was truncated) and fixed it by editing the suhosin.ini file, something like this(uncommented some lines and increased the values):

; Filtering Options
;suhosin.filter.action =
;suhosin.cookie.max_array_depth = 100
;suhosin.cookie.max_array_index_length = 64
;suhosin.cookie.max_name_length = 64
;suhosin.cookie.max_totalname_length = 256
;suhosin.cookie.max_value_length = 10000
;suhosin.cookie.max_vars = 100
;suhosin.cookie.disallow_nul = on
suhosin.get.max_array_depth = 150
suhosin.get.max_array_index_length = 164
suhosin.get.max_name_length = 164
suhosin.get.max_totalname_length = 512
suhosin.get.max_value_length = 1024
suhosin.get.max_vars = 500
suhosin.get.disallow_nul = on
suhosin.post.max_array_depth = 500
suhosin.post.max_array_index_length = 1024
suhosin.post.max_name_length = 164
suhosin.post.max_totalname_length = 1256
suhosin.post.max_value_length = 650000
suhosin.post.max_vars = 1200
suhosin.post.disallow_nul = on
suhosin.request.max_array_depth = 500
suhosin.request.max_array_index_length = 1024
suhosin.request.max_totalname_length = 1256
suhosin.request.max_value_length = 650000
suhosin.request.max_vars = 1200
suhosin.request.max_varname_length = 164
suhosin.request.disallow_nul = on
;suhosin.upload.max_uploads = 25
;suhosin.upload.disallow_elf = on
;suhosin.upload.disallow_binary = off
;suhosin.upload.remove_binary = off
;suhosin.upload.verification_script =
;suhosin.session.max_id_length = 128
 [2010-07-07 10:52 UTC] pajoye@php.net
-Status: No Feedback +Status: Feedback
 [2010-07-07 10:52 UTC] pajoye@php.net
We don't support PHP 4 anymore and we never supported patched PHP (like with Suhosin).

Please try again with a recent PHP version, unpatched.
 [2012-10-17 14:39 UTC] vincentwansink at shaw dot ca
I am having this problem now with version 5.4.0.  I am shocked to see that this 
issue has been around since 2003 and it is still happening.  I've been using PHP 
for about 8 years and never came across this before.  Also this just started 
happening to me after I moved my site to a brand new server and upgraded to 
version 5.4 so I'm guessing there must be some unique configuration combination 
that causes this to happen.

I am having it happen with small text fields (20 characters or less).  Being 
able to rely on post back data is obviously critical to any PHP application so 
why is this bug still around?  It's embarassing to have to tell my clients "I 
don't know why it's doing that".
 [2013-02-18 00:04 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 [2013-04-02 01:54 UTC] chris at manhattaninteractive dot com
Seems like I have the original issue, but not with the same symptoms of all the off-topic add ins over the years. Ubuntu 12.04, php 5.3.10-1ubuntu3.6

Problem exists in all browsers (yes, FF 19.0.2), did not with same scripts on previous system (centos, php 5x). TamperData shows the request going out with:


18:16:20.556[227ms][total 227ms] Status: 200[OK]
POST http://XXXXXXXXX.com/YYYYYYYYY/TARGET_SCRIPT.php Load Flags[LOAD_BYPASS_CACHE  LOAD_BACKGROUND  INHIBIT_CACHING  ] Content Size[1303] Mime Type[text/html]
   Request Headers:
      Host[XXXXXXXXX.com]
      User-Agent[Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0]
      Accept[application/json, text/javascript, */*; q=0.01]
      Accept-Language[en-US,en;q=0.5]
      Accept-Encoding[gzip, deflate]
      DNT[1]
      Content-Type[application/x-www-form-urlencoded; charset=UTF-8]
      X-Requested-With[XMLHttpRequest]
      Referer[http://XXXXXXXXX.com/YYYYYYYYYYY/ZZZZZZZ1.php]
      Content-Length[89]
      Authorization[Basic cHJfZGVtb1VzZXI6NElQY01F]
      Connection[keep-alive]
      Pragma[no-cache]
      Cache-Control[no-cache]
   Post Data:
      customerID[915690000000000000000000000000c4f]
      reportTitle[Sample]
      responseFormat[json]
      toolName[newRep]
      sub1[6000000]
      sub2[]
      sub3[]
   Response Headers:
      Date[Tue, 02 Apr 2013 01:16:21 GMT]
      Server[Apache/2.2.22 (Ubuntu)]
      Vary[Accept-Encoding]
      Content-Encoding[gzip]
      Content-Length[1303]
      Keep-Alive[timeout=5, max=100]
      Connection[Keep-Alive]
      Content-Type[text/html]


Problem is, the php script called only gets the first three post vars. This is 100% consistent, I have tried expanding the suhosin caps, and also disabling suhosin completely (via "suhosin.simulation = On" in php.ini) with no change in behavior. It is shocking to me that a critical issue like this has been allowed to persist for 10 years!
 [2016-02-11 04:04 UTC] mukutmanimishra at yahoo dot co dot in
Hi,
I am facing problem when submitting form in backend php to save form data in database so $_POST variable is showing empty. i am using latest version of php wamp server.pls suggest.due o this Undefined index error showing on the page.

( ! ) Notice: Undefined index: first_name in C:\wamp\www\FinalMyCourse\regdb.php on line 11
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0

( ! ) Notice: Undefined index: first_name in C:\wamp\www\FinalMyCourse\regdb.php on line 29
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0
ArrayArrayArrayArrayAll fields are required.
array
  'middle_name' => 
    array
      0 => string 'hj' (length=2)
  'last_name' => 
    array
      0 => string 'h' (length=1)
  'ages' => string 'jhkjh' (length=5)
  'mobileno' => 
    array
      0 => string '786987' (length=6)
  'email' => 
    array
      0 => string 'hjkjh@qwe.com' (length=13)
  'password' => string '' (length=0)
  'password_confirmation' => string '' (length=0)
  'timepass' => string 'Hindi' (length=5)
  'address' => string '' (length=0)
  'city' => string '' (length=0)
  'skills' => string '' (length=0)
  'totexp' => string '' (length=0)
  'prefslot' => string 'Weekend' (length=7)
  'preftiming' => string 'Morning' (length=7)
  'regsubmit' => string 'Register' (length=8)

( ! ) Notice: Undefined index: first_name in C:\wamp\www\FinalMyCourse\regdb.php on line 47
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0

( ! ) Warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in C:\wamp\www\FinalMyCourse\regdb.php on line 48
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0
2	0.0045	406008	mysqli_real_escape_string ( )	..\regdb.php:48

( ! ) Warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in C:\wamp\www\FinalMyCourse\regdb.php on line 49
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0
2	0.0047	406136	mysqli_real_escape_string ( )	..\regdb.php:49

( ! ) Warning: mysqli_real_escape_string() expects parameter 2 to be string, array given in C:\wamp\www\FinalMyCourse\regdb.php on line 50
Call Stack
#	Time	Memory	Function	Location
1	0.0006	397728	{main}( )	..\regdb.php:0
2	0.0048	406216	mysqli_real_escape_string ( )	..\regdb.php:50
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 16:01:29 2024 UTC