php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #57621 $_POST not working if enctype is multipart/form-data and apc.rfc1867 = on
Submitted: 2007-04-13 13:19 UTC Modified: 2008-09-07 01:10 UTC
From: federico at galassi dot net Assigned:
Status: Closed Package: APC (PECL)
PHP Version: 5.2.0 OS: gentoo linux
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
31 + 4 = ?
Subscribe to this entry?

 
 [2007-04-13 13:19 UTC] federico at galassi dot net
Description:
------------
Upgrading to APC 3.0.13 (3.0.14 same effect) i found out
that all my php scripts doing form processing (with enctype="multipart/form-data" because of file uploading) were not able to get posted values anymore, except for the uploaded file itself which is working fine.
keys are set but values are empty. I had rfc1867 on
because i wanted to try the upload progress bar trick.
I downgraded back to 3.0.12 and all is fine. A friend of mine is running 3.0.13 with rfc1867 = off and it's doing good, so
i guess the problem is related with rfc1867 itself.

Reproduce code:
---------------
--- /upload.html
<form action="/upload.php" method="post" enctype="multipart/form-data" />
<input type="file" name="myfile" />
<input type="hidden" name="forum_id" value="123" />
<input type="submit" value="upload" />
</form>

--- /upload.php
<?php
print_r($_POST);

Expected result:
----------------
Array
(
    [forum_id] => 123
)

Actual result:
--------------
Array
(
    [forum_id] => 
)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-04-26 07:27 UTC] tomas at tomas-muller dot net
FYI:
Not able to reproduce on FreeBsd-6.2, PHP-5.2.1 w/Suhosin 0.9.6.2 + pecl-APC-3.0.14
 [2007-05-14 08:24 UTC] gopalv82 at yahoo dot com
Not able to reproduce it in APC current CVS + php 5.2.2

Please pastebin your phpinfo(); output, if you have anything unusual there. Other than that it WFM.
 [2007-07-12 10:51 UTC] Stefan dot Rothenhofer at tilllate dot com
I encounter the same problem as Federico.

If i turn apc.rfc1867 to 1 there is no $_POST Data anymore. I noticed that if i turn on magic_quotes_gpc in my php.ini that it works again (with rfc1867 to 1).

So is this a bug or a wrong configuration of apc.ini and php.ini?

My Versions are "php 5.2.2-pl1-gentoo" and "pecl-apc 3.0.14".

Additional php.ini configuration:
variables_order = "EGPCS"
register_globals = Off
register_long_arrays = Off
auto_globals_jit = On
always_populate_raw_post_data = Off
register_argc_argv = On
 [2007-09-06 11:18 UTC] hans at velum dot net
I can confirm this broken behavior on Gentoo with PHP 5.2.4 and APC 3.0.14.
 [2007-10-11 03:47 UTC] admin at litecat dot com
I have the same problem on Debian (php 5.2.0-8) but with usual forms (not multipart) :(
 [2007-10-29 13:26 UTC] hans at velum dot net
This is still happening w/ PHP 5.2.4 + the recently-released APC 3.0.15.  

I also tried disabling suhosin, as I figured that could be involved in this, but that didn't help the issue.
 [2007-11-08 05:28 UTC] phofstetter at sensational dot ch
Hi,

confirming this here. Also, this was a FastCGI-Setup where the upload tracking in APC doesn't work anyways - I just forgot to turn it off again.

PHP-5.2.4
APC 3.0.14
Lighttpd 1.4.18

I can provide shell access to a similarely configured machine if needed.

Philip
 [2007-12-03 04:00 UTC] xellzhang at gmail dot com
I met this problem too. I tried to use APC module to get uploading progress (with rfc1867 is set to 'On').
My environment:
PHP 5.2.5-pl0-gentoo
APC 3.0.15
 [2007-12-08 15:27 UTC] thomas at partyflock dot nl
I believe the problem is the newlength parameter of the event_formdata structure.
This newlength parameter points towards a size_t newlength variable which is initialized to 0.
Most logical fix seem to be to initialize this newlength variable to new_val_len instead of zero.
 [2008-04-08 13:58 UTC] jhibbard at hsr dot com
Same problem here.  Running FreeBSD 6.2-RELEASE-p7

Not to sound redundant, but fix is to turn apc.rfc1867 to off.

Any ETA on a fix for this?  Must be something with the new update as downgrading seems to fix it.
 [2008-04-08 14:02 UTC] jhibbard at hsr dot com
FYI, I'm using version 3.0.18 of APC for FreeBSD.
 [2008-07-06 21:36 UTC] gavinmroy at gmail dot com
Confirmed this behavior with APC 3.0.19 and PHP Version 5.2.6RC4-pl0-gentoo.  Turning on GPC does "fix" the behavior as previously stated.   This is not a acceptable bug fix for this behavior though.
 [2008-08-16 09:09 UTC] tomas at tomas-muller dot net
Any news? Is there any fix, patch or workaround (other than turning on GPC)? This issue is a real pain in my ass since my users are uploading 100M+ files :(
 [2008-08-25 15:33 UTC] torben dot sorensen at gmail dot com
Hello - I found this was not working for me either - then I found this comment which is useful for the Gentoo people: 

One point to check is that you requiere a mpm-prefork apache2 install to put to work APC ..

I haven't tested yet tho ...
 [2008-08-25 18:47 UTC] tomas at tomas-muller dot net
This seems to be a bug of php rfc1867 handler.
There's a "patch" that worked for me: http://bugs.php.net/bug.php?id=43540
 [2008-08-27 14:33 UTC] shire@php.net
I'd love to implement a fix for this bug, but I think nobody is able to reproduce this easily on a fresh build.  As Gopal requested, if someone can send us more information specifically their full php config, apache, php, and apc versions, architecture, and OS. we might get closer to reproducing this.

Thanks!
 [2008-09-07 01:10 UTC] shire@php.net
Looks like a possible fix for this has been checked into CVS.
see: http://bugs.php.net/bug.php?id=43540
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 15:01:28 2024 UTC