php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #30683 Change in behavious of FILES array between 4.3.6 and 4.3.7_3
Submitted: 2004-11-04 06:11 UTC Modified: 2010-11-18 23:47 UTC
From: bugs at bsdfirst dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 4 OS: FreeBSD
Private report: No CVE-ID: None
 [2004-11-04 06:11 UTC] bugs at bsdfirst dot com
Description:
------------
Hi,

I have two FreeBSD servers detailed as follows:

lassa:
FreeBSD 4.10-STABLE
php4-4.3.7_3
apache+mod_ssl+mod_deflate-1.3.31+2.8.18+1.3.14.12+1.0.21_4

honk:
FreeBSD 4.9-RELEASE
php4-4.3.6
apache+mod_ssl+mod_deflate-1.3.29+2.8.16+1.0.20_3

I am using a HTML form (enctype="multipart/form-data") to upload image files to each server.

On the server honk I am using the function isurlorfile to allow the user to type a URL instead of selecting a file in the <INPUT type="file"> box.

Selecting a file for upload works correctly in both cases.  C:\Pics\test.png yields the following the in $_FILES array:

honk & lassa:
$_FILES['pic']['name'] contains 'test.png'

However entering a URL only works on the server honk.  Entering the URL http://localhost/test.png into the <INPUT type="file"> box on the form yields the following results in the $_FILES array:

honk:
$_FILES['pic']['name'] contains 'http://localhost/test.png'

lassa:
$_FILES['pic']['name'] contains 'test.png'

Honk is our development server and we have written code relying on this undocumented feature.

Obviously the behavious exhibited on the server honk is usefull as a user can select a file or enter a URL to a file in the one input field.

Which of these is the expected behaviour?  Is there an expected behaviour and what behaviour would I expect from a more current version of PHP?  Could I request the behaviour exibited on the server honk be a documented feature?

Thanks,
Patrick Brennan

Reproduce code:
---------------
function _isurlorfile(&$str) {
  if (is_uploaded_file($str['tmp_name']) && $str['size']) {
    return $str['tmp_name'];
  } elseif (ereg('^http|ftp', $str['name'])) {
    return $str['name'];
  } else {
    return 0;
  }
}


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-11-04 16:43 UTC] bugs at bsdfirst dot com
I have just confirmed that 4.3.9 also behaves in the same manner as 4.3.7_3.  It would appear that this was a bug fix to prevent a security exploit (use paths containing ../).  I wonder if there shouldn't be a way to obtain the contents of a <INPUT type="file"> field in it's entirety?  Particually since you cannot use php://input whilst POSTing a mulipart mime form.  This could either be another entry in the $_FILES array, for example $_FILES['pic']['orig_path'] or $_FILES['pic']['name'] could check for '^http:||ftp:'.  The former is probably the most compatible and the least security risk (a user could not accidentally use it - they would have to make a deliberate choice).  What are the chances of having something like that added into the 4 series?  With all of this in mind I have changed the category of this report to Feature Request.  Thanks, Patrick
 [2010-11-18 23:47 UTC] jani@php.net
-Status: Open +Status: Bogus -Package: Feature/Change Request +Package: *General Issues -PHP Version: Irrelevant +PHP Version: 4
 [2010-11-18 23:47 UTC] jani@php.net
Possibly already fixed. Try newer version.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 07:01:28 2024 UTC