I'm using WAMP in my local machine, when a FORM(method="POST") with 2000 input fields is submitted I'm able to read only 1001 _POST variable. i.e With Netbeans debugger I can clearly see _POST size is always 1001 if there are more than 1001 input fields in the form.
The same is working fine in another machine(WAMP), where I can see all the POST variables.
Please help me to solve my problem.
PHP 5.3.9 introduced the max_input_vars config option, which is defaulted to a value of 1000. Check out the Runtime Configuration section of the PHP manual. The default value and the change log are at the top of the page.
The value can be changed by updating the server's php.ini, adding an .htaccess file, or adding a line to httpd.conf.
If you are using Suhosin with Hardened PHP, you might be hitting a maximum variables limit that it imposes. In your php.ini, you can just add
[suhosin]
suhosin.request.max_vars = 1000
suhosin.post.max_vars = 1000
changing 1000 to whatever you want and restart your webserver.
I ran into this on the Drupal Permissions page when there were a lot of modules installed with a large number of roles, which resulted in a ton of checkboxes. It would only save a certain number of them before anything after would just get ignored.
It sounds like this is probably not your problem, but since it's fairly likely that someone in the future may stumble upon this when searching for something related I'll go ahead and throw this in since it took me ages to figure out when I was stumped.
I solved my $_POST max inputs -problem by adding the following to php.ini:
max_input_vars = 5000
suhosin.request.max_vars = 5000
suhosin.post.max_vars = 5000
Note the suhosin.request.max_vars also.
I solved this problem. Open the PHP.INI configuration file and add these lines
[suhosin]
suhosin.post.max_vars = 20000
suhosin.request.max_vars = 20000
I suspect the problem is with the amount of data coming with your POST request. There is no setting which limits the number of $_POST vars that can be set. However there is a memory limit for POST data which is 8MB by default.
In your php.ini file try modifying the value of post_max_size and set it to a higher value. Don't forget to restart apache after the change is made.
Related
I am trying to upload a file using uppy. On my server I am using php 8.0 and Apache 2.
I am uploading a file which is about 156Mb in size but server returns response with 413 status code and no message.
As per instruction given on all over internet I tried to configure my php.ini file and here are the updated configurations
post_max_size = 20480M
upload_max_filesize = 20480M
max_execution_time = 24000
max_input_time = 24000
memory_limit = 800M
Unfortunately above settings didn't help me. I have confirmed the php.ini file location with following command
php -i | grep Conf
Apart from this, I came across an answer that asked to set SecRequestBodyLimit value in modsecurity.conf. modsecurity was not even installed in my system but still I installed it and set the SecRequestBodyNoFilesLimit value as SecRequestBodyLimit 1000000000 but no luck.
I highly doubt that this is from server and Uppy has no role in this issue but I cannot predict the exact problem.
Response 413 is a typical error when you use ModSecurity, and the limit was set incorrectly. You should review the relevant documentation. If the size of your file is 156MB, you should calculate the base64 encoded size: multiply it with 4 and divide it by 3, so the approximate value is 208MB. I should set up 250MB for SecRequestBodyLimit, but not for SecRequestBodyNoFilesLimit - please keep it as low. 250MB is 262144000 byte, so try to set up this:
SecRequestBodyLimit 262144000
Also please check your Apache's error.log, you have to see every relevant information there.
It seems like there is a problem with older PHP versions and more than 1000 input fields in one form (see this question).
If I run a webserver with an older PHP version, is there a limit to the maximum number of form elements in (one nesting level) like it is controlled by the php.ini directive max_input_vars since PHP 5.3.9?
Or is there no limit in older versions?
What happens if I set this variable anyway in older versions in php.ini or .htaccess?
I noticed, that on my server I run PHP 5.3.3-7+squeeze17 which also already has the directive max_input_vars.
How exactly did older versions behave?
It seems there is confusion:
http://www.flowstopper.org/2012/12/my-php-wtf-of-day-maxinputvars.html
Although the docs say: "Available since PHP 5.3.9."
http://php.net/manual/en/info.configuration.php
If I had to guess I would say there was always a limit, and it just got pulled out into the config/documentation in 5.3.9
There seems to be a bug in older versions:
https://bugs.php.net/bug.php?id=65778
although you can alter the directive in php.ini and the change is shown correctly in phpinfo(), it has no effect.
Behaviour: all variables exceeding 1000 are ignored
tested in PHP 5.3.3-7+squeeze17 without suhosin module
A possible workaround: compact all form-data with javascript
I think your problem is not the number of yourform fields, I think the total data you are sending is to much.
There is an php.ini directive that limits how much data you totally can send on a post request (check: post_max_size).
But you can not change post_max_size while runtime (because this value is checked before the first line of you php files during input phase of php).
Your have several ways to change this value:
In Webserver Config
in a htaccess file
with the following code:
php_value post_max_size 512M # set maximum post data to 512 MB
in your global php.ini
in your users.ini (if it's configured)
with the following code:
post_max_size = 512M
I have a weird memory problem in PHP. I think something is only allowing an array to be a maximum of 0.25M. It appears the script is only using up to around 6M before it crashes.
Here's the output from xdebug:
Here's the function it is calling. The result of the sql query is about 800 rows of text.
public function getOptions(){
$sql = "select Opt,
Code,
Description
from PCAOptions";
$result = sqlsrv_query($this->conn,$sql);
$arrayResult = array();
echo ini_get('memory_limit'); //this confirms that my memory limit is high enough
while($orderObject = sqlsrv_fetch_object($result,'PCA_Option')){
array_push($arrayResult, $orderObject);
}
return $arrayResult;
}
So, I don't know how or why this worked, but I fixed the problem by commenting out these two lines from my .htaccess file:
# php_value memory_limit 1024M
# php_value max_execution_time 18000
I did this because I noticed phpinfo() was returning different values for these settings in the two columns "master" and "local".
My php.ini had memory_limit=512M and max_execution_time=3000, whereas my .htacces file had the above values. I thought .htaccess would just override whatever was in php.ini but I guess it caused a conflict. Could this be a possible bug in php?
There's a number of steps some PHP distributions, security packages, and web hosts take to prevent users from raising the PHP actual memory limit at runtime via ini_set. The most likely candidate is the suhosin security package.
This older Stack Overflow question has a number of other suggestions as well.
When working with 'big' scripts which i know will bypass my server PHP memory limits,
i always set this variable at the beginning of the script. Works all the time.
ini_set("memory_limit","32M"); //Script should use up to 32MB of memory
I was running approximately PHP Version 5.3.5. I wanted to enable SOAP, and upgraded to PHP Version 5.3.13 using webtatic repo. Everything is working great! Except...
I POST some an array using Ajax. The full array is posted by the client, but it appears the server only receives the first 1,000 elements of the array.
I looked into php.ini, and can't see any limit.
Please advise.
I flagged this as a duplicate of PHP Warning: Unknown: Input variables exceeded 1000 but the OP there had a different problem. Thus here the solution from the comments:
When PHP 5.3.9+ returns exactly 1000 variables and / or array elements, you run into security limit, see php.ini:max-input-vars. PHP Versions before that can run into the same problem caused by a similar limit imposed by suhosin, see its config
Increase the limit or change the way you transfer the data.
In php.ini there is the following configuration directive:
; Maximum size of POST data that PHP will accept.
; http://php.net/post-max-size
post_max_size = 8M
In php.ini look for
post_max_size = 10M
http://support.microsoft.com/kb/208427 says IE has limits of about 2k, I do remember HTML has some limits but I thought the HTML limit was on get not post.
is there any limit of POST arguments? I have situation where on dev server my form with over 520 args is posted and saved without problems, where on production env it saves only up to 499 args...
Any ideas?
I don't think there is a limit to the number of variables sent through POST, just on their accumulated size. The limit varies from server to server.
Update: The Suhosin PHP hardening patch can in fact impose a limit on the number of request variables. The default is 2001000. Suhosin is installed by default on Ubuntu, so it could be the reason for your problem. Info courtesy of #Pascal Martin, cheers!
There are two factors to limiting the POST maximum size:
The PHP setting post_max_size
Indirectly, also the PHP setting max_input_vars
You can find out its value using phpinfo().
And the web server's limits:
LimitRequestBody in Apache
MaxClientRequestBuffer on IIS
In your specific case, you may want to add what kind of server you are running this on, and how big the data is. Are the 520 arguments coming anywhere near post_max_size? What happens if you do a print_r($_REQUEST) in the receiving script?
Also, in PNP.INI file there is a setting:
max_input_vars
which in my version of PHP: 5.4.16 defaults to 1000.
From the manual:
"How many input variables may be accepted (limit is applied to $_GET, $_POST and $_COOKIE superglobal separately)"
Ref.: http://www.php.net/manual/en/info.configuration.php#ini.max-input-vars
Yes, this is controlled by the directive post_max_size, which is 8M by default.
The number of arguments doesn't matter, but you probably exceed the limit in your production.
You can run ini_get('post_max_size') in both environments to see if there is a difference.
You can't change it from ini_set, however it is possible to change the directive from .htaccess.
i think the POST limit is whatever is configured in php.ini (8M by
default?)
You need to increase POST_MAX_SIZE in php.ini (or use ini_set() on the page).
http://uk.php.net/manual/en/ini.core.php#ini.post-max-size