By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
445,876 Members | 1,239 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 445,876 IT Pros & Developers. It's quick & easy.

able to upload 28 meg file, yet php.ini limits posts to 10 megs.What is up with that?

P: n/a

To guard against our users possibly uploading huge files, I've got this
in my php.ini file:

; Maximum size of POST data that PHP will accept.
post_max_size = 10M
On a server running Ubuntu Linux. The PHP version:

root@ldc310:/etc/php5/cli# php -v
PHP 5.1.6 (cli) (built: Nov 28 2007 22:52:49)

I just uploaded a 28 meg file to the server. I have a PHP script that
automatically resizes the images to less than a meg. However, I was
assuming that the upload should have failed, before the PHP script ever
had the chance to resize the file. How do I limit how much our users can
upload? I really don't want the users to have the power to upload 30 or
40 or 50 meg files.

The server does have Plesk installed, which I know, in times past, has
found ways to undermine the settings in php.ini. For instance, for
open_basedir, the value that gets written in the httpd.conf file, in
each vhost directory, takes precedence over whatever I put in php.ini.
But I've never seen Plesk undermine the importance of the post_max_size
setting, nor can I imagine where Plesk might store such a conf setting
if it did.

Any thoughts on what might be wrong? Are there other places some
configuration data might be taking precedent?
Jun 2 '08 #1
Share this Question
Share on Google+
16 Replies


P: n/a
NC
On May 30, 7:01 pm, Lawrence Krubner <lawre...@krubner.comwrote:
>
To guard against our users possibly uploading huge files, I've
got this in my php.ini file:

; Maximum size of POST data that PHP will accept.
post_max_size = 10M
What about upload_max_filesize? And what, if anything, is
LimitRequestBody directive in Apache set to? Are there any .htaccess
files that could possibly change any of this?

And while we're checking for possibilities, are you editing the same
php.ini PHP is using?

Also, are you running PHP as an Apache module or CGI/FastCGI?

Cheers,
NC
Jun 2 '08 #2

P: n/a
NC wrote:
On May 30, 7:01 pm, Lawrence Krubner <lawre...@krubner.comwrote:
>To guard against our users possibly uploading huge files, I've
got this in my php.ini file:

; Maximum size of POST data that PHP will accept.
post_max_size = 10M

What about upload_max_filesize?

From my php.ini file:

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

And what, if anything, is
LimitRequestBody directive in Apache set to?
This returns nothing:

root@ldc310:~# cd /etc/apache2/
root@ldc310:/etc/apache2# grep -R LimitRequestBody *

So I assume it is not set.
Are there any .htaccess
files that could possibly change any of this?
No, not at the top level of the site, where the upload script is.

And while we're checking for possibilities, are you editing the same
php.ini PHP is using?
I assume, but how could I be sure? This tells me the version:

root@ldc310:/var/www/vhosts/thesecondroad.org/httpdocs# php -v
PHP 5.1.6 (cli) (built: Nov 28 2007 22:52:49)

Since it is PHP version 5, I assume this is the right path for editing:

root@ldc310:/# nano /etc/php5/cli/php.ini

Any way I can be sure? How do I check?

Also, are you running PHP as an Apache module or CGI/FastCGI?
An Apache module.

-- lawrence

Jun 2 '08 #3

P: n/a
NC
On May 31, 12:04 am, Lawrence Krubner <lawre...@krubner.comwrote:
NC wrote:
And what, if anything, is LimitRequestBody directive
in Apache set to?

This returns nothing:

root@ldc310:~# cd /etc/apache2/
root@ldc310:/etc/apache2# grep -R LimitRequestBody *

So I assume it is not set.
And if it's not set, it takes the default value, zero (meaning, no
limit).
And while we're checking for possibilities, are you editing
the same php.ini PHP is using?

I assume, but how could I be sure?
Run phpinfo() FROM THE BROWSER, not from command line. Look for
"Configuration File (php.ini) Path" in the output. The command-line
interpreter, the server module, and the CGI/FastCGI executable can
each have a different php.ini...
Since it is PHP version 5, I assume this is the right path for
editing:

root@ldc310:/# nano /etc/php5/cli/php.ini
I don't think so; note the "cli" in the path. Looks like you're
editing the php.ini that's used by the command-line interpreter,
not the one used by the Apache module.
Any way I can be sure? How do I check?
See the bit on phpinfo() above.

Cheers,
NC
Jun 2 '08 #4

P: n/a
On May 31, 3:01 am, Lawrence Krubner <lawre...@krubner.comwrote:
To guard against our users possibly uploading huge files, I've got this
in my php.ini file:

; Maximum size of POST data that PHP will accept.
post_max_size = 10M

On a server running Ubuntu Linux. The PHP version:

root@ldc310:/etc/php5/cli# php -v
PHP 5.1.6 (cli) (built: Nov 28 2007 22:52:49)

I just uploaded a 28 meg file to the server. I have a PHP script that
automatically resizes the images to less than a meg. However, I was
assuming that the upload should have failed, before the PHP script ever
had the chance to resize the file. How do I limit how much our users can
upload? I really don't want the users to have the power to upload 30 or
40 or 50 meg files.

The server does have Plesk installed, which I know, in times past, has
found ways to undermine the settings in php.ini.
No - override - exactly as it's supposed to do. But its worth noting
that the only time I've seen plesk is on hosted servers - which rather
implies that you're already paying somebody to answer these questions.
For instance, for
open_basedir, the value that gets written in the httpd.conf file, in
each vhost directory, takes precedence over whatever I put in php.ini.
But I've never seen Plesk undermine the importance of the post_max_size
setting, nor can I imagine where Plesk might store such a conf setting
if it did.

Any thoughts on what might be wrong? Are there other places some
configuration data might be taking precedent?
The post_max_size is PHP specific thing - assuming it did work as you
expect, it wouldn't stop anyone from posting more data to the
webserver - indeed, according to the manual, it only says that when
more than this limit is posted, the $_POST and $_GET vars are empty -
no mention of $_FILES. A better setting would be to set the limit
using upload_max_filesize, but again this does not stop people from
abusing your bandwidth.

If you set the limit in the webserver config then it will terminate
the conenction.

C.
Jun 2 '08 #5

P: n/a
On Sat, 31 May 2008 13:38:57 +0200, C. (http://symcbean.blogspot.com/)
<co************@gmail.comwrote:
On May 31, 3:01 am, Lawrence Krubner <lawre...@krubner.comwrote:
>To guard against our users possibly uploading huge files, I've got this
in my php.ini file:

; Maximum size of POST data that PHP will accept.
post_max_size = 10M

On a server running Ubuntu Linux. The PHP version:

root@ldc310:/etc/php5/cli# php -v
PHP 5.1.6 (cli) (built: Nov 28 2007 22:52:49)

I just uploaded a 28 meg file to the server. I have a PHP script that
automatically resizes the images to less than a meg. However, I was
assuming that the upload should have failed, before the PHP script ever
had the chance to resize the file. How do I limit how much our users can
upload? I really don't want the users to have the power to upload 30 or
40 or 50 meg files.

The server does have Plesk installed, which I know, in times past, has
found ways to undermine the settings in php.ini.

No - override - exactly as it's supposed to do. But its worth noting
that the only time I've seen plesk is on hosted servers - which rather
implies that you're already paying somebody to answer these questions.
Well, even on my personal VPS I have Plesk. Really takes the edge of
administrative tasks I have no interest in for a hobby server :)
>For instance, for
open_basedir, the value that gets written in the httpd.conf file, in
each vhost directory, takes precedence over whatever I put in php.ini..
But I've never seen Plesk undermine the importance of the post_max_size
setting, nor can I imagine where Plesk might store such a conf setting
if it did.

Any thoughts on what might be wrong? Are there other places some
configuration data might be taking precedent?

The post_max_size is PHP specific thing - assuming it did work as you
expect, it wouldn't stop anyone from posting more data to the
webserver - indeed, according to the manual, it only says that when
more than this limit is posted, the $_POST and $_GET vars are empty -
no mention of $_FILES. A better setting would be to set the limit
using upload_max_filesize, but again this does not stop people from
abusing your bandwidth.

If you set the limit in the webserver config then it will terminate
the conenction.
If concerned, it would be best to limit at the source indeed, i.e. the
webserver. If one wants to do it in PHP, a php_admin_value in httpd.conf/
vhost config should work. They ought not be overridable bij .htaccess
files, and as max_upload_filesize is PHP_INI_PERDIR since 4.2.3 an
ini_set() shouldn't work either.
--
Rik Wasmus
....spamrun finished
Jun 2 '08 #6

P: n/a
On May 31, 6:38 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
If you set the limit in the webserver config then it will terminate
the conenction.
I probably should not get involved in a discussion like this, but I
can't help it. If the purpose is to save bandwidth, does the webserver
terminate the connection *after* if has uploaded to the specified
limit?

If tat is the case, that would be wasteful for an upload. Is there not
a facility that one could write just before the upload function is
involved to check the size of the file on the client and not start the
upload at that point? That would seem to be more bandwidth-sensible?

Jun 2 '08 #7

P: n/a
NC wrote:
On May 31, 12:04 am, Lawrence Krubner <lawre...@krubner.comwrote:
>NC wrote:
>>And what, if anything, is LimitRequestBody directive
in Apache set to?
This returns nothing:

root@ldc310:~# cd /etc/apache2/
root@ldc310:/etc/apache2# grep -R LimitRequestBody *

So I assume it is not set.

And if it's not set, it takes the default value, zero (meaning, no
limit).
>>And while we're checking for possibilities, are you editing
the same php.ini PHP is using?
I assume, but how could I be sure?

Run phpinfo() FROM THE BROWSER, not from command line. Look for
"Configuration File (php.ini) Path" in the output. The command-line
interpreter, the server module, and the CGI/FastCGI executable can
each have a different php.ini...
>Since it is PHP version 5, I assume this is the right path for
editing:

root@ldc310:/# nano /etc/php5/cli/php.ini

I don't think so; note the "cli" in the path. Looks like you're
editing the php.ini that's used by the command-line interpreter,
not the one used by the Apache module.


Thanks for catching that. Seems you were right.

If anyone has time and wants to do me a big favor, go here:

http://www.cyberbitten.com/my_private_page.php

login with:

user: test
password: test

then go here and try to upload a file that is bigger than 10 megs:

http://www.cyberbitten.com/my_privat...=mp_photos.htm
I appreciate anyone who can give this a test.
-- lawrence krubner



Jun 2 '08 #8

P: n/a
On May 31, 10:45 am, Lawrence Krubner <lawre...@krubner.comwrote:
NC wrote:
On May 31, 12:04 am, Lawrence Krubner <lawre...@krubner.comwrote:
NC wrote:
>And what, if anything, is LimitRequestBody directive
in Apache set to?
This returns nothing:
root@ldc310:~# cd /etc/apache2/
root@ldc310:/etc/apache2# grep -R LimitRequestBody *
So I assume it is not set.
And if it's not set, it takes the default value, zero (meaning, no
limit).
>And while we're checking for possibilities, are you editing
the same php.ini PHP is using?
I assume, but how could I be sure?
Run phpinfo() FROM THE BROWSER, not from command line. Look for
"Configuration File (php.ini) Path" in the output. The command-line
interpreter, the server module, and the CGI/FastCGI executable can
each have a different php.ini...
Since it is PHP version 5, I assume this is the right path for
editing:
root@ldc310:/# nano /etc/php5/cli/php.ini
I don't think so; note the "cli" in the path. Looks like you're
editing the php.ini that's used by the command-line interpreter,
not the one used by the Apache module.

Thanks for catching that. Seems you were right.

If anyone has time and wants to do me a big favor, go here:

http://www.cyberbitten.com/my_private_page.php

login with:

user: test
password: test

then go here and try to upload a file that is bigger than 10 megs:

http://www.cyberbitten.com/my_privat...=mp_photos.htm

I appreciate anyone who can give this a test.

-- lawrence krubner
I've started an upload of a 20MB .exe file(Nessus-3.2.1.exe).

As I said in another post, perhaps you want to do a few checks to save
your bandwidth. Check that the file type is correct. Check the size
*before* you start the upload.

I'll report back if the upload crashes.
Jun 2 '08 #9

P: n/a
On May 31, 11:04 am, MikeB <MPBr...@gmail.comwrote:
On May 31, 10:45 am, Lawrence Krubner <lawre...@krubner.comwrote:
NC wrote:
On May 31, 12:04 am, Lawrence Krubner <lawre...@krubner.comwrote:
>NC wrote:
>>And what, if anything, is LimitRequestBody directive
>>in Apache set to?
>This returns nothing:
>root@ldc310:~# cd /etc/apache2/
>root@ldc310:/etc/apache2# grep -R LimitRequestBody *
>So I assume it is not set.
And if it's not set, it takes the default value, zero (meaning, no
limit).
>>And while we're checking for possibilities, are you editing
>>the same php.ini PHP is using?
>I assume, but how could I be sure?
Run phpinfo() FROM THE BROWSER, not from command line. Look for
"Configuration File (php.ini) Path" in the output. The command-line
interpreter, the server module, and the CGI/FastCGI executable can
each have a different php.ini...
>Since it is PHP version 5, I assume this is the right path for
>editing:
>root@ldc310:/# nano /etc/php5/cli/php.ini
I don't think so; note the "cli" in the path. Looks like you're
editing the php.ini that's used by the command-line interpreter,
not the one used by the Apache module.
Thanks for catching that. Seems you were right.
If anyone has time and wants to do me a big favor, go here:
http://www.cyberbitten.com/my_private_page.php
login with:
user: test
password: test
then go here and try to upload a file that is bigger than 10 megs:
http://www.cyberbitten.com/my_privat...=mp_photos.htm
I appreciate anyone who can give this a test.
-- lawrence krubner

I've started an upload of a 20MB .exe file(Nessus-3.2.1.exe).

As I said in another post, perhaps you want to do a few checks to save
your bandwidth. Check that the file type is correct. Check the size
*before* you start the upload.

I'll report back if the upload crashes.
I can't tell if it failed or uploaded successfully. I don't get an
error message or anything... ?
Jun 2 '08 #10

P: n/a
MikeB wrote:
On May 31, 6:38 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
>If you set the limit in the webserver config then it will terminate
the conenction.

I probably should not get involved in a discussion like this, but I
can't help it. If the purpose is to save bandwidth, does the webserver
terminate the connection *after* if has uploaded to the specified
limit?
The webserver doesn't KNOW what php's bandwidth limit is. It takes ALL
the POST data of which the uploaded file is part, and gives it to PHP.
If tat is the case, that would be wasteful for an upload. Is there not
a facility that one could write just before the upload function is
involved to check the size of the file on the client and not start the
upload at that point? That would seem to be more bandwidth-sensible?
Jun 2 '08 #11

P: n/a
On Sat, 31 May 2008 19:12:24 +0200, The Natural Philosopher <a@b.cwrote:
MikeB wrote:
>On May 31, 6:38 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
>>If you set the limit in the webserver config then it will terminate
the conenction.
I probably should not get involved in a discussion like this, but I
can't help it. If the purpose is to save bandwidth, does the webserver
terminate the connection *after* if has uploaded to the specified
limit?

The webserver doesn't KNOW what php's bandwidth limit is. It takes ALL
the POST data of which the uploaded file is part, and gives it to PHP.
Indeed, it can only enforce it's own limitations, not PHP's. And that's
where any reasonable limitation should take place, as it can and will drop
a connection, instead of just (like PHP) ignoring the data but still
allowing it to get in AFAIK.
--
Rik Wasmus
....spamrun finished
Jun 2 '08 #12

P: n/a
MikeB wrote:
On May 31, 10:45 am, Lawrence Krubner <lawre...@krubner.comwrote:
>NC wrote:
>>On May 31, 12:04 am, Lawrence Krubner <lawre...@krubner.comwrote:
NC wrote:
And what, if anything, is LimitRequestBody directive
in Apache set to?
This returns nothing:
root@ldc310:~# cd /etc/apache2/
root@ldc310:/etc/apache2# grep -R LimitRequestBody *
So I assume it is not set.
And if it's not set, it takes the default value, zero (meaning, no
limit).
And while we're checking for possibilities, are you editing
the same php.ini PHP is using?
I assume, but how could I be sure?
Run phpinfo() FROM THE BROWSER, not from command line. Look for
"Configuration File (php.ini) Path" in the output. The command-line
interpreter, the server module, and the CGI/FastCGI executable can
each have a different php.ini...
Since it is PHP version 5, I assume this is the right path for
editing:
root@ldc310:/# nano /etc/php5/cli/php.ini
I don't think so; note the "cli" in the path. Looks like you're
editing the php.ini that's used by the command-line interpreter,
not the one used by the Apache module.
Thanks for catching that. Seems you were right.

If anyone has time and wants to do me a big favor, go here:

http://www.cyberbitten.com/my_private_page.php

login with:

user: test
password: test

then go here and try to upload a file that is bigger than 10 megs:

http://www.cyberbitten.com/my_privat...=mp_photos.htm

I appreciate anyone who can give this a test.

-- lawrence krubner

I've started an upload of a 20MB .exe file(Nessus-3.2.1.exe).

As I said in another post, perhaps you want to do a few checks to save
your bandwidth. Check that the file type is correct. Check the size
*before* you start the upload.

I'll report back if the upload crashes.
You can't tell the "file type" until the file is uploaded. All you know
is the file name - and a .jpg file does not necessarily have to be a
..jpg file - it could be anything.

You also don't know the size before the file is uploaded - again, all
you know is the size provided by the browser (if it is - it may not be).

And you can't check anything in your code before the file is uploaded
anyway - your code doesn't get control until after the file is uploaded.

There are ways to control the size in HTML, but those can be ignored by
the browser.

In short, you can't guarantee anything about the file until it has been
uploaded.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Jun 2 '08 #13

P: n/a
Jerry Stuckle wrote:
You can't tell the "file type" until the file is uploaded. All you know
is the file name - and a .jpg file does not necessarily have to be a
.jpg file - it could be anything.

You also don't know the size before the file is uploaded - again, all
you know is the size provided by the browser (if it is - it may not be).

And you can't check anything in your code before the file is uploaded
anyway - your code doesn't get control until after the file is uploaded.

There are ways to control the size in HTML, but those can be ignored by
the browser.

In short, you can't guarantee anything about the file until it has been
uploaded.
Use Flash
an example to check file details before upload
http://www.tink.ws/blog/files/flash8...ceExample.html
Jun 27 '08 #14

P: n/a
Jerry Stuckle wrote:
You can't tell the "file type" until the file is uploaded. All you know
is the file name - and a .jpg file does not necessarily have to be a
.jpg file - it could be anything.

You also don't know the size before the file is uploaded - again, all
you know is the size provided by the browser (if it is - it may not be).

And you can't check anything in your code before the file is uploaded
anyway - your code doesn't get control until after the file is uploaded.

There are ways to control the size in HTML, but those can be ignored by
the browser.

In short, you can't guarantee anything about the file until it has been
uploaded.
Use Flash
an example to check file details before upload
http://www.tink.ws/blog/files/flash8...ceExample.html
Jun 27 '08 #15

P: n/a
On Mon, 02 Jun 2008 08:19:56 +0200, Daniele <da*****************@yahoo.it>
wrote:
Jerry Stuckle wrote:
>You can't tell the "file type" until the file is uploaded. All you
know is the file name - and a .jpg file does not necessarily have to be
a .jpg file - it could be anything.
You also don't know the size before the file is uploaded - again, all
you know is the size provided by the browser (if it is - it may not be).
And you can't check anything in your code before the file is uploaded
anyway - your code doesn't get control until after the file is uploaded.
There are ways to control the size in HTML, but those can be ignored
by the browser.
In short, you can't guarantee anything about the file until it has
been uploaded.
Use Flash
an example to check file details before upload
http://www.tink.ws/blog/files/flash8...ceExample.html

It can help, yes, however, it's optional. By which I mean that if you can
upload with Flash, one can upload without it. True, it would be a hurdle
for less savvy users, but someone wanting to bypass the rules would still
have no trouble doing that.
--
Rik Wasmus
....spamrun finished
Jun 27 '08 #16

P: n/a
MikeB wrote:
On May 31, 6:38 am, "C. (http://symcbean.blogspot.com/)"
<colin.mckin...@gmail.comwrote:
>If you set the limit in the webserver config then it will terminate
the conenction.

I probably should not get involved in a discussion like this, but I
can't help it. If the purpose is to save bandwidth, does the webserver
terminate the connection *after* if has uploaded to the specified
limit?

If tat is the case, that would be wasteful for an upload. Is there not
a facility that one could write just before the upload function is
involved to check the size of the file on the client and not start the
upload at that point? That would seem to be more bandwidth-sensible?
It doesn't seem to specify this in Apache's documentation, but it does
in fact check the Content-Length header of the incoming request before
servicing it at all (meaning it will terminate the connection before any
file data is transferred).

That still assumes that the request is honest, though; it won't really
help you in the case of a dedicated attacker.

Jeremy
Jun 27 '08 #17

This discussion thread is closed

Replies have been disabled for this discussion.