Re: Fwd: [PHP] upload_max_size vs. post_max_size

From: Date: Sun, 12 Nov 2000 02:33:26 +0000
Subject: Re: Fwd: [PHP] upload_max_size vs. post_max_size
References: 1  Groups: php.dev 
Request: Send a blank email to php-dev+get-37794@lists.php.net to get a copy of this message
Just adding my 2bytes.... Andi Gutmans wrote: > Is it really that necessary to have the two of them? Can't there be a > comment next to post_max_size noting that this effects file uploads too? > >From: Micah Anderson <micah@colltech.com> > >People use POST on a php page that I maintain - sometimes up to 100meg files > >(and boy does that take a while)... I, too, handle such a system.... > > I previously had to set upload_max_size > >in php.ini for it to work correctly, but I recently upgraded to the 4.0.3pl1 > >and quickly the complaints came in - uploads larger than 8MB weren't going > >through. > > Then I took a look at my PHP core > >and found the NEW variable: post_max_size and it was set to 8MB. > >I changed that to 100mb and now it works. But there is NO documentation > >available ANYWHERE about what post_max_size is, or how it is different from > >upload_max_size, and should I have memory_limit set higher too? Should I > >just have post_max_size set? Or should I have both, or all three? Well, this is starting to seem a bit silly, and not very elegant. We already have: MAX_FILE_SIZE (in the form) upload_max_filesize (php.ini) memory_limit (php.ini) And now: post_max_size (php.ini) Do we also have to start using: get_max_size ? cookie_max_size ? put_max_size ? session_max_size ? I can see "memory_limit", that makes sense for code that spirals out of control, grabbing up memory, regardless of file upload, input, disk, etc. For a max_file_size, that can also make sense in the context of a file write which is independant of upload/put/get (say, a PDF being generated from a database select), but it would also need to be set for similar *reasons* as post_max_size, i.e. concerns about running out of disk... but get/post/cookie/whatever are all in a group about variable passing, and (possibly?) buffer overruns, right? (I know cookies are now limited anyways, but my point is more about ease of use and elegance). I would suggest that we include the following in php.ini: 1. memory_limit, to handle programs spiralling into hopeless disk thrashing. 2. max_file_size, to control the maximum amount of disk used by a given PHP instance. The rest are really only *subvalues* of the memory_limit, and in some cases, max_file_size. I think the real confusion is coming from the file upload using so many different variables, in both an upload form (not where it really belongs, as it's pointless from a security standpoint) and in the php.ini file. Backwards compatibility: If there _is_ a custom setting for one of the above, it should be honored, so if a user wanted to limit posts, gets, whatever, they *could*. Otherwise, they should default to their parent value(s). Example: If there is only a memory limit, all other mem variables should use that as the maximum. If there is a custom value for something else, it should be honored. That way, we can make this easier to set, don't lose backwards compatibility, and avoid spiralling into the land of max_mysql_select_return_data_size, max_non_post_filesize, etc. -Ron -- Brought to you from iBop the iMac, a MacOS, Win95, Win98, LinuxPPC machine, which is currently in MacOS land. Your bopping may vary.

« previous php.dev (#37794) next »