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

go to bug id or search bugs for

Doc Bug #45283 extract($_FILES) result unpredictable
Submitted: 2008-06-16 17:20 UTC Modified: 2009-08-28 06:44 UTC
Votes:3
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: php at info-svc dot com Assigned:
Status: Closed Package: Documentation problem
PHP Version: 5.2.6 OS: *
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: php at info-svc dot com
New email:
PHP Version: OS:

 

 [2008-06-16 17:20 UTC] php at info-svc dot com 
Description:
------------
After receiving reports of a broken feature, the problem was traced to extract($_FILES) producing different results on different servers.

A server running PHP 5.2.5 gave the expected result where $variable['tmp_name'] contained the uploaded file path.  A server running PHP 5.2.3 gave the unexpected result where $variable['tmp_name'] always dumped as string(1) "/"

The workaround is to use $_FILES['tmp_name'] in which case both servers gave the expected result.

I am stumped as to whether this is caused by a bug that was fixed between versions or some configuration issue I am not aware of?

Robert Chapin
Chapin Information Services, Inc.

Reproduce code:
---------------
<form method="POST">
<input name="themefile" type="file" />
<input type="submit" />
</form>
<?php
extract($_FILES, EXTR_SKIP);
var_dump($themefile);
var_dump($themefile['tmp_name']);
?>

Expected result:
----------------
array(5) {
  ["name"]=>
  string(20) "samplefile.txt"
  ["type"]=>
  string(24) "application/octet-stream"
  ["tmp_name"]=>
  string(18) "/var/tmp/phpSJkwr0"
  ["error"]=>
  int(0)
  ["size"]=>
  int(379)
}
string(18) "/var/tmp/phpSJkwr0"

Actual result:
--------------
string(14) "/tmp/phpZOtyB7"
string(1) "/"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-06-16 17:39 UTC] php at info-svc dot com 
Note about the "Reproduce code", for best results use
<form method="POST" enctype="multipart/form-data">
 [2008-06-16 18:09 UTC] php at info-svc dot com 
Adding to the confusion, I thought perhaps the unexpected behavior could be caused by the register_globals configuration.  However, according to documentation ...

http://www.php.net/manual/en/faq.misc.php#faq.misc.registerglobals

... extract($_FILES, EXTR_SKIP); is the correct way to emulate register_globals On.  I dumped all of the other superglobals and confirmed the only one containing a 'themefile' index was $_FILES.  Both var_dump($_POST); and var_dump($_GET); returned "array(0) {}"
 [2008-06-19 04:59 UTC] php at info-svc dot com 
I confirmed this behavior with PHP 5.2.6 running on IIS and Windows 2003 SP2.

Test case output with register_globals Off

array(5) {
  ["name"]=>
  string(14) "samplefile.txt"
  ["type"]=>
  string(10) "text/plain"
  ["tmp_name"]=>
  string(25) "C:\WINDOWS\Temp\php57.tmp"
  ["error"]=>
  int(0)
  ["size"]=>
  int(459)
}
string(25) "C:\WINDOWS\Temp\php57.tmp"

Test case output with register_globals On

string(25) "C:\WINDOWS\Temp\php58.tmp"
string(1) "C"

So I'm convinced that register_globals is involved here.  There is something horribly wrong with this feature or its documentation.
 [2008-07-02 12:26 UTC] jani@php.net 
It's documentation issue. Plus you really should NOT be using register_globals=On. And using extract() on $_FILES...well..that's very flaky idea to begin with. Just don't do it. :)
 [2008-11-05 11:15 UTC] vrana@php.net 
Results of extract() shouldn't depend on register_globals.
 [2008-11-05 19:55 UTC] php at info-svc dot com 
On the other hand, if register_globals is broken then extract($_FILES, EXTR_SKIP); is working as intended, skipping keys already registered.  I can understand it's either a bug or a documentation problem, but something isn't right here.
 [2008-11-08 01:37 UTC] jani@php.net 
Why this needs documenting:

1. It's not a bug.
2. Changing this would break BC.
3. register_globals is off by default
4. register_globals will be gone in next major version.
 [2009-08-28 06:43 UTC] svn@php.net 
Automatic comment from SVN on behalf of torben
Revision: http://svn.php.net/viewvc/?view=revision&revision=287827
Log: Documented what happens when you use extract() on $_FILES with
EXTR_SKIP when register_globals is turned on. Also noted that good
coding practice means you should never see this.
Addresses Bug #45283.
Also fixed some minor grammatical problems.
 [2009-08-28 06:44 UTC] torben@php.net 
This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Mon May 20 07:01:34 2024 UTC