Re: Fwd: [PHP] upload_max_size vs. post_max_size

Any idea who/when added the post_max_size variable? Andi At 07:33 PM 11/11/00 -0700, Ron Chmara wrote:

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.

--- Andi Gutmans <andi@zend.com> http://www.zend.com/