$_FILES is empty. Tried EVERYTHING.

[HundredHandedSlap]

All I did was recompile PHP 4.3.4 with the included GD and now
$_FILES is perpetually empty. I tried recompiling again
without GD to fix the problem, to go back to what I had before, but
$_FILES is always empty. I am running Mandrake 9.2 - this is like the ONLY thing I've installed on it besides vnc, apache2 and mysql 4.

Here is how I ran configure:
[root@localhost php-4.3.4]# ./configure
--with-apxs2=/usr/local/apache2/bin/apxs --with-mysql
--prefix=/usr/local/php434 --with-gd (also tried without gd again)

Here is what I'm using to test fix attempts:

<?
error_reporting(E_ALL);
print_r($_FILES);
if (empty($_FILES)) {
echo &quot;\$_FILES is empty<br>\n&quot;; //this prints
}
echo $_FILES['player1photo']['error']; //$_FILES is empty anyway.
echo '<form method=&quot;POST&quot; enctype=&quot;multipart/form-data&quot;>
<input type=&quot;file&quot; name=&quot;player1photo&quot;
accept=&quot;image/gif;image/jpeg&quot;/>
<input type=&quot;submit&quot;/></form>';
//echo phpinfo();
?>

and here is the relevant portion of my php.ini (and yes, I've tried
channging upload_tmp_dir to a dir that is 777. No good. (and why
should I have to anyway, it worked before)).
;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default
if not
; specified).
upload_tmp_dir =/tmp

; Maximum allowed size for uploaded files.
upload_max_filesize = 2M

Here's the perms on /tmp:
drwxrwxrwt 11 root root 4096 Feb 17 18:48 tmp/

I even tried recompiling apache and then php again, again. I also tried &quot;--without-pear&quot;. WHY WHY????

 

[LaundroMat]

Did you set the max_file_size in your form as well?
Don't forget the:

<input type=&quot;hidden&quot; name=&quot;MAX_FILE_SIZE&quot; value=&quot;1024&quot;>

With value being the amount in bytes.

 

[HundredHandedSlap]

I just tried it, with &quot;1000000000&quot;, no good. thanks for trying, anything else?

 

[sleipnir214]

What should the value be of the &quot;action&quot; attribute of your form tag?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[HundredHandedSlap]

The action attribute isn't required. And it wasn't there
before when it was working, either.

anyone else?

 

[sleipnir214]

That is not correct. The HTML 4.01 specification, as published by w3.org, states that the &quot;action&quot; attribute is required.

Browsers may react well to the absence of the attribute, but don't depend on that. Browser behavior changes over time.


Is $_FILES empty regardless of the size of the file? If you send a 1-byte file, is it still empty?

What is the setting of LimitRequestSize in Apache's httpd.conf?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[HundredHandedSlap]

The HTML 4.01 spec, as well as the XHTML specs are irrelevant. They do not include several propietary elements which some (major) browsers require you to use to achieve certain layouts. This is the browser's fault, but so what? Among other things, those specs prohibit nesting the < form> element in < table> and < tr> elements, which is required in order to avoid the page break caused by < form. Even the XHTML transitional DTD has these problems.

Browsers change over time, and so does the spec. The browsers lead, the HMTL spec follows. (not true with other w3 specs though. Also, the xhtml spec is useful for making html into xml of course.)

Thanks for your suggestion. I don't have LimitRequestSize in my httpd.conf. I just tried sending a 1 byte file, no go. Also, I've tried uploading the same file via a perl cgi and that worked, but not in php. To humor you, I tried setting the action attrib as well, no go.

thanks

 

[sleipnir214]

There is a difference between disagreeing with the spec over nesting of elements and not providing an attribute that actually tells the browser to where to send a form's data, thus making your HTML dependent on a web browser publisher's assumption of undocumented default behavior. It's something to think about.


How are you running PHP? As an Apache module, or as a CGI?

What is the setting in php.ini for post_max_size ?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[Bastien]

is the enctype=&quot;multipart/form-data&quot; in the form tag? kinda obvious i know, but gotta look at everything

Bastien

Any one have a techie job in Toronto, I need to work...being laid off sucks!

 

[HundredHandedSlap]

&quot;thus making your HTML dependent on a web browser publisher's assumption of undocumented default behavior&quot;

I'm already dependant on the web browser publisher's implementation- that's my point. I'm ONLY dependant on the web browser implementation! Being dependant on the spec is irrelevant! Good example is CSS- the browsers are so far out of whack that I am right to throw the spec out the window- if I do what it says, my pages won't look right. Where the spec and the browser disagree, to hell with the spec.

Apache module,
Setting in php.ini is:
post_max_size = 8M

And to Bastien- yep. (actually, scroll up I put my code in the first post).

thanks you two,
hhs

 

[sleipnir214]

There is a difference. If a browser publisher suddenly decided to stop supporting the <table> tag, users would have a reason to complain and force the publisher to change his ways. All it took for Mi&cent;ro$oft to back off changing their site to IE-specific XML was Tim Berners-Lee's pointing out that their XML didn't follow the spec.

If a browser publisher suddenly decides that if the &quot;action&quot; attribute is missing and users complain, all the browser manufacturer has to do is say, &quot;Look at the spec. The 'action' attribute is required.&quot; Then you're going back to modify all your old web pages.



Were there any warnings when you recompiled PHP?

Does other POST-method data (coming from a non-file type input) get through?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[sleipnir214]

On a console at your Apache/PHP machine, if you do

tail -f /path/to/httpd/error_log


And then try to upload the page, does Apache report any errors?

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[HundredHandedSlap]

Yea thanks I already tried that, tailing the error log didn't produce any errors.

But I've figured out my problem.

Here is is:

http://tinyurl.com/225ns

thanks for your help (all of you)

 

[sleipnir214]

Please explain.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[HundredHandedSlap]

Oh I'm sorry-

In short, during isntallation, I created the php.ini file on the wrong location (a location that php was NOT looking), because of an error in the documentation (NOT my fault!) So, my line:
upload_tmp_dir =/tmp
was never being read. Instead, php had no php.ini file so it was using it's own defaults.

And now the long version:

The way I found it was, I was looking at the documentation at php.net for file upload. It didn't tell me anything I didn't know, but it reminded me that it derives it's temp dir location from the env variable $TMP. Just out of curiosity, not expecting to fix anything, I tried:

[root@localhost apache2]# echo $TMP
/root/tmp

So naturally, I checked the perms on /root/tmp, but they were 777. But the enclosing dir (/root) was like 600. So when I changed the perms on that dir, it worked.

So that lead me to figure out that my php.ini settings weren't sticking, and you can guess the rest.

Lastly- the question of &quot;why did file uploads ever work that way, before I recompiled?&quot;. Well, before I stopped apache/php so that I could install GD, apache/php had been loaded at boot. My guess is, that when it loaded at boot, it's environment variable $TMP may have been &quot;/tmp&quot;, hence it was working. The env variables during the various &quot;boot levels&quot; during boot could be different from the way they are when root logs in as a human. In fact, I'm just now realizing that they MUST be different- because remember how you have to use absolute paths when you do stuff in rc.local? That's because there's no PATH set yet..., so the envs aren't the same as when root logs in.

That's my guess. It sure as hell wasn't &quot;/root/tmp&quot; or it wouldn't have been working.

again, thanks for your responses sleipnir214.
hhs