Any reason why $_FILES['userfile']['error'] wouldn't be populated?

This is a discussion on Any reason why $_FILES['userfile']['error'] wouldn't be populated? within the PHP Language forums, part of the PHP Programming Forums category; Hi, I am in the middle of writing an image upload script and am limiting the size of uploads via ...


Go Back   Usenet Forums > PHP Programming Forums > PHP Language

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 05-27-2007
lister
 
Posts: n/a
Default Any reason why $_FILES['userfile']['error'] wouldn't be populated?

Hi,

I am in the middle of writing an image upload script and am limiting
the size of uploads via upload_max_filesize. This all seems to be
working well, and if I try and upload a bigger file then I get an
UPLOAD_ERR_INI_SIZE sat in $_FILES['userfile']['error']. All hunkey
dorey.

However, in my testing there are one or two large files that cause
problems. PHP appears to abort the upload early as it should, but when
my script runs, $_FILES isn't populated at all?!

I have tried to narrow down the difference in these file but I can't
seem to find anything definate. All the ones that fail are AVI or WMV
files if that gives any clue, but even if I rename them to MPG (others
of which work ok), and check the MIME type being sent up has also
changed to mpg, then they still fail as before. I have sent bigger and
smaller files all ok, so it's not size. I can't see anything in the
filename itself that would cause problems.

Any ideas?

Reply With Quote
  #2 (permalink)  
Old 05-27-2007
Andy Hassall
 
Posts: n/a
Default Re: Any reason why $_FILES['userfile']['error'] wouldn't be populated?

On 27 May 2007 04:38:47 -0700, lister <listerofsmeg01@hotmail.com> wrote:

>I am in the middle of writing an image upload script and am limiting
>the size of uploads via upload_max_filesize. This all seems to be
>working well, and if I try and upload a bigger file then I get an
>UPLOAD_ERR_INI_SIZE sat in $_FILES['userfile']['error']. All hunkey
>dorey.
>
>However, in my testing there are one or two large files that cause
>problems. PHP appears to abort the upload early as it should, but when
>my script runs, $_FILES isn't populated at all?!
>
>I have tried to narrow down the difference in these file but I can't
>seem to find anything definate. All the ones that fail are AVI or WMV
>files if that gives any clue, but even if I rename them to MPG (others
>of which work ok), and check the MIME type being sent up has also
>changed to mpg, then they still fail as before. I have sent bigger and
>smaller files all ok, so it's not size. I can't see anything in the
>filename itself that would cause problems.


Do you have error_reporting set to E_ALL? Are there any errors in the Apache
log? (in case PHP's done something unusual - although it doesn't sound like
it's dumping core). What version of PHP?
--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Reply With Quote
  #3 (permalink)  
Old 05-27-2007
lister
 
Posts: n/a
Default Re: Any reason why $_FILES['userfile']['error'] wouldn't be populated?


> Do you have error_reporting set to E_ALL? Are there any errors in the Apache
> log? (in case PHP's done something unusual - although it doesn't sound like
> it's dumping core). What version of PHP?
> --
> Andy Hassall :: a...@andyh.co.uk ::http://www.andyh.co.ukhttp://www.and....co.uk/space:: disk and FTP usage analysis tool- Hide


Thanks for your pointers. Yes, I have E_ALL reporting on. On looking
in the Apache error log I found I was getting a error about exceeding
post_max_size on the ones that fail, but bizarrely not on the ones
that work, but yet those are larger!! I can only assume there is some
bug in PHP when checking post_max_size because the large ones that
work are VERY large (2GB) (post_max_size is set to 2M)

OK, so checking the PHP site reveals that what I am experiencing seems
to be correct:
"If the size of post data is greater than post_max_size, the $_POST
and $_FILES superglobals are empty. This can be tracked in various
ways, e.g. by passing the $_GET variable to the script processing the
data, i.e. <form action="edit.php?processed=1">, and then checking if
$_GET['processed'] is set."

Thanks again for your help.


Reply With Quote
  #4 (permalink)  
Old 05-27-2007
Andy Hassall
 
Posts: n/a
Default Re: Any reason why $_FILES['userfile']['error'] wouldn't be populated?

On 27 May 2007 10:36:10 -0700, lister <listerofsmeg01@hotmail.com> wrote:

>> Do you have error_reporting set to E_ALL? Are there any errors in the Apache
>> log? (in case PHP's done something unusual - although it doesn't sound like
>> it's dumping core). What version of PHP?

>
>Thanks for your pointers. Yes, I have E_ALL reporting on. On looking
>in the Apache error log I found I was getting a error about exceeding
>post_max_size on the ones that fail, but bizarrely not on the ones
>that work, but yet those are larger!!


What enctype do you have on the <form> for the upload? If you don't have
enctype="multipart/form-data", it'll upload it using
application/x-www-form-urlencoded.

Because of this, certain files may be encoded to data several times larger
than their original size - but it depends on the content of the file. Mostly
ASCII files would be closer to their original sizes.

>I can only assume there is some
>bug in PHP when checking post_max_size because the large ones that
>work are VERY large (2GB) (post_max_size is set to 2M)


With files that large then you quite likely run into various 32-bit integer
limits. Many versions of Apache have issues with 2Gb+ files, let alone PHP.
--
Andy Hassall :: andy@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool
Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On




All times are GMT +1. The time now is 06:00 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0