Bug #19263 [Com]: huge POST data corrupt

Edit report at https://bugs.php.net/bug.php?id=19263&edit=1 ID: 19263 Comment by: klaipedaville at gmail dot com Reported by: erwin at isiz dot com Summary: huge POST data corrupt Status: Not a bug Type: Bug Package: Apache2 related Operating System: Solaris 8 PHP Version: 4CVS-2002-09-06 Block user comment: N Private report: N New Comment: Hello, 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! Regards, Dennis. Previous Comments: ------------------------------------------------------------------------ [2004-05-04 14:56:32] richardks666 at hotmail dot com Solved! 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! ------------------------------------------------------------------------ [2004-05-03 12:46:40] richardks666 at hotmail dot com Hey 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 ------------------------------------------------------------------------ [2003-11-21 11:11:38] 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 ------------------------------------------------------------------------ [2003-11-19 08:38:43] 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 </Files> 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-10-02 21:07:44] 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 </Files> (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. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=19263 -- Edit this bug report at https://bugs.php.net/bug.php?id=19263&edit=1