Re: [PHP-DEV] Fwd: [PHP] upload_max_size vs. post_max_size From: Andi Gutmans (andi <email protected>)
Date: 11/12/00

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 <email protected>>
> > >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 <email protected>>
http://www.zend.com/

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>