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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: bugs at bsdfirst dot com
New email:
PHP Version: OS:

 

 [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

Pull Requests

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-2025 The PHP Group
All rights reserved.
Last updated: Tue Jul 01 00:01:36 2025 UTC