|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #19263 huge POST data corrupt
Submitted: 2002-09-06 08:03 UTC Modified: 2002-09-10 01:49 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: erwin at isiz dot com Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 4CVS-2002-09-06 OS: Solaris 8
Private report: No CVE-ID: None
 [2002-09-06 08:03 UTC] erwin at isiz dot com

I've gave this the summary "huge POST data", because I've found two bugs, which are, in my opinion, related.

The first one: 
If I upload a file using the file upload example from the php website, all I get are corrupted files. The resulting files are about two times bigger then the input files. The amount of bytes on the output varies a little bit. This does not happens with files of 10 Kb, but different files which vary from 60-120 Kb got corrupted.

The second one:
If I post text in a textarea, nothing goes wrong. But if I post a lot of text in a textarea, parts of the text is copied into the text itself. For instance, I copied the source of (normal HTML source) in a textarea. Posted the data to info.php (this script only has the phpinfo() function, so I can see all data). The sourcecode of the php website is 376 lines long. The result is about 734 lines. This is around twice as big (The site looks really weird ;-))

Again, I think these two are related. They only occured in conjunction with Apache 2.0.40 (didn't test other Apache 2 releases). I'm sure that the bug is a PHP bug, because Perl code doesn't have this problem (but I rather use PHP)
I did test it with php-4.2.2, which gave me the same results.

PHP Configure line:
'./configure' '--with-mysql=/usr/local/mysql' '--enable-track-vars' '--with-openssl=/usr/local/ssl/' '--with-zlib' '--enable-ftp' '--with-gd' '--enable-gd-native-ttf' '--with-pdflib' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-freetype-dir=/usr/local' '--prefix=/usr/local/httpd/php' '--with-zlib-dir=/usr' '--with-apxs2=/usr/local/httpd/bin/apxs'



Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-09-10 01:49 UTC] erwin at isiz dot com
I've found the problem:

don't add SetOutputFilter PHP and SetInputFilter PHP to the Apache config. Only use AddType application/x-httpd-php .php

Grtz Erwin
 [2003-01-08 14:21 UTC] colreid at zasx dot com
People are asking me what I did, so here it is:
My Apache2 package has a directory which it uses for included files with httpd.conf (the path to this directory in my installation is /etc/httpd/conf.d).
In there is a file called php.conf, and basically I just commented out the whole thing except for one line:

LoadModule php4_module modules/

This section here:
#<Files *.php>
#    SetOutputFilter PHP
#    SetInputFilter PHP
#    LimitRequestBody 524288
liked to munge uploads.

Also, in the httpd.conf file I added the line:
AddType application/x-httpd-php .php .html .htm .inc

And that's it.  I restarted apache and uploads decided to be nice.  :)
 [2003-07-01 02:35 UTC] php at gijs dot triple-it dot nl

On my configuration (RedHat 9.0, Apache 2.0.40, php-4.2.2), I had to remove one of the following from the conf/httpd.conf or the /conf.d/php.conf

AddType application/x-httpd-php .php4 .php3 .phtml .php


<Files *.php*>
    SetOutputFilter PHP
    SetInputFilter PHP
    LimitRequestBody 10240000

Either of these functions will work, but together they screw up and create the problem as reported above.

Good Luck!

Gijs Zonneveld
 [2003-10-02 21:07 UTC] josantri at hotmail dot com
Same experience with RedHat 7.3, Apache 2.0.45 & PHP 4.3.1.
The solution was disabling MIME type for PHP (I don't see new problems by now with this issue):

#AddType application/x-httpd-php .php

And now, leaving enabled filtering method, but be care with above example or you get a 'Syntax error [...]:
AddInputFilter requires at least two arguments, input filter name (or ; delimited names) followed by one or more file extensions' when Apache2 is restarted. The code we use is:

<Files *.php>
 AddInputFilter PHP .php
 AddOutputFilter PHP .php

(Note the field naming the extension.)

I'm not sure how enable filtering for *php.*, because AddInputFilter and AddOutputFilter seems not to accept wildcards on extensions (in files section definition is fine). Probably, independent definitions for each extension will work as well.

Thanks to all of the above for help provided.
 [2003-11-19 08:38 UTC] grall at mit dot edu
You are right erwin about this bug.

The bug is in Apache 2.0.40
Possibly upgrading to a newer version will solve this.
In any case, using the 'AddType application/x-httpd-php .php' didn't work for me, but instead I had to just insert
into my httpd.conf:

<Files *.php*>
    SetOutputFilter PHP
    SetInputFilter PHP
    LimitRequestBody 10240000

Some people report that you have to choose between one or the other, but in my case the second choice is the only one that works. Incidentally, if you are using MulitViews (as I am), using the <Files> approach, Multiviews no longer works. This is more of an Apache problem, but whatever, this thread is about that problem. Any suggestions?
 [2003-11-21 11:11 UTC] contact at creation-online dot net
Hi !!!

You really help me because I had the same problem with Apache 2 and Php 4.3.4

Now it works very good because of you solution ;-)

Best regards, Aur?lien
 [2004-05-03 12:46 UTC] richardks666 at hotmail dot com

I am on Apache 2.0.40 using PHP5 RC2, experiencing the same problems as you guys did. Going to try these solutions later on today, but I wanted to tell  you that as seen, this problem exist in PHP5 RC2 as well.

If these are not the solutions to my problem, which I hope they are, wrongly linked LIBJPEGs and other libraries might interfere. 

Last night I sniffed the data between the webserver and my dev. computer, which showed that the instant I choose to upload my image (depends on filetype of course), that the appropriate library is linked and executed even there, and at the time, my PHP code hasn't been ran. In my case the Header dump contained the libjpeg version 1 addon.

One might also wish to comment that, in conjunction with the original post, I too receive very odd FORM data. The size is somewhat correct ( I didn't doublecheck ) but extra objects are posted, for instance if I got an array of id[], then it might contain awkward data. Solution for that was to simply attach a INPUT TYPE HIDDEN nameing it "dummy" or something with a dummy value, now the objects are passed correctly.

Staying in touch
 [2004-05-04 14:56 UTC] richardks666 at hotmail dot com
I removed /etc/httpd/conf.d/php.conf
and updated /etc/httpd/conf/httpd.conf with:
AddType application/x-httpd-php .php .phtml .phtm .inc .oc
and restarted the webserver, things were back to normal. Was quite frustrating!
 [2014-03-11 21:12 UTC] klaipedaville at gmail dot com

Although the post is as old as the hills but I still ran into the same problem on Apache 2.2.22, PHP 5.4.4-14, and Debian 7 (Squeeze). The funniest thing is that none of the suggested here solutions work. As mentioned by Erwin files of any type and up to 20 Kb upload fine but anything above 20 Kb gets corrupt after uploading. Error reporting says absolutely nothing anywhere. For example I get the following from the print_r($_FILES), 

Array ( [uploadedfile] => Array ( [name] => test.doc [type] => application/msword [tmp_name] => /uploads/php3t4UJX [error] => 0 [size] => 83376 ) )

The uploaded file's size in this case is 83376 when the original was 41688 (doubled the size during the process of uploading). The server settings are most probably OK as the files do upload and all the other code works well except for going double in size if over 20 Kb and getting corrupt as a result.

I cannot really seem to get it solved. If that is a new combo issue (apache + debian + php) or anything else from the latest updates I would be really grateful for any tips / pointers about how to solve this and what might be the latest work around. Many thanks!

 [2014-05-22 15:44 UTC] klaipedaville at gmail dot com
Hello again,

I thought I would let everybody know how I solved it.

Well, the problem was in php5 module that was missing. This was ridiculous! The latest Linux update on Debian like this 'apt-get update' actually messed it up from packages. For some reason it did not install php5_module or php5 or (which happens to be the same thing). I solved it like this by typing on the command line the following:

a2enmod php5 

It said no such files or directories in ../path/php5.load 

Then I ran on the command line this:

apt-file search php2.load 

It replied that the package that contains php2.load file is called libapache2-mod-php5.

Now I have simply run the command:

apt-get install libapache2-mod-php5

It also installed all the other missing dependencies for php5.

Final note. I am not sure what might have caused it but the fact remains on hand. The php5 module was missing for some reason and it was the culprit for all the trouble. Even though the bug is old and it was fixed earlier but missing a module re-introduces the same bug from old times again. I hope it will help someone who may run into the same trouble. As you can see I did not touch / change anything at all except for updating everything from packages which is a regular, common and preferred practice.

Best of luck to all.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue May 21 01:01:31 2024 UTC