Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

pcharitou's avatar

POST Request is severely limited despite changes to server configuration

Hello all,

I have a form within my application which allows the user to dynamically create form input fields and have them submitted as an array to the backend. Think adding rows to a table and submitting the table. As it stands, each row has 6 variables.

The problem is, no matter what I've done (will include a list below) I cannot get the request to contain more than 165 items in said array (total of 990 input vars).

What I've tried:

  • Updating php.ini (within both CLI and FPM despite knowing it comes from CLI just to be sure). I set arbitrarily high limits for all the fields changed just to be 100% sure I wasn't hitting some random cap.
    • max_input_time = 60
    • max_input_nesting_level 248
    • max_input_vars = 9999
    • memory_limit 2048M
    • post_max_size = 128M

One thing to note is all of the inputs are alphanumeric and relatively small (max of maybe 6 characters each)

  • Updating nginx.conf for HTTP (site is running on HTTPS though, again just to be cautious)

  • Removing any middleware though none was created specifically to affect requests

  • Suhosin is not being used

  • There are no restrictions such as "client_max_body_size" within my sites-available/enabled config files

  • There are no traces in my log files

The form submits and gets immediately dumped to the browser. I know the dump is not an issue because I've dumped much larger inputs in the past (not that this could even be an issue? I don't know)

The Request class used is the standard illuminate one, nothing custom to eliminate that possibility.

Any and all help is greatly appreciated.

Form:

<form method="POST" action="{{ route('resource-example.update', $resource_example->id) }}" enctype="multipart/form-data">
            @csrf
			...
</form

Route:

Route::resource('/resource-example', ResourceExampleController::class);

Controller:

 public function update(Request $request, $id)
    {
        dd($request->all());
	}
0 likes
10 replies
LaryAI's avatar
Level 58

It seems like you've covered a lot of the common issues that could cause a limitation on the number of input variables. However, there are a few more things you can check and try to resolve this issue:

  1. Check for .user.ini or .htaccess files: Sometimes, local .user.ini (for PHP-FPM) or .htaccess (for Apache) files can override the php.ini settings. Make sure there are no such files in your application directory that might be setting max_input_vars or other related configurations.

  2. Verify PHP Info: Create a PHP file with the following content and navigate to it in your browser to ensure that your php.ini changes are being recognized by PHP.

<?php
phpinfo();

Look for the max_input_vars and other related configurations to confirm they are set to the values you expect.

  1. Check if PHP is running as FPM or mod_php: Depending on how PHP is running on your server, the configuration files might be different. For PHP-FPM, you would typically modify the php.ini file, but for mod_php, you might need to set these values in .htaccess.

  2. Check for server-level restrictions: If you're using a shared hosting or a managed server, there might be server-level restrictions that you cannot override. Contact your hosting provider to confirm if this is the case.

  3. Check for application-level limits: Some frameworks or libraries might impose their own limits on request size. Since you're using Laravel, check if there's any middleware or package that could be affecting the request size.

  4. Increase max_input_nesting_level: Although you've set max_input_nesting_level to 248, if your form has a complex structure with deeply nested arrays, you might need to increase this value even more.

  5. Check for browser limitations: While unlikely, it's possible that the browser has limitations on the amount of data it can send in a single request. Try submitting the form with a different browser or using a tool like Postman to rule out browser-related issues.

  6. Check for Laravel-specific issues: Since you're using Laravel's Request class, ensure that there's no configuration in Laravel that might be affecting the input variables. You can also try accessing the raw POST data using PHP's file_get_contents('php://input') to see if the issue is with PHP or Laravel's handling of the request.

If none of these steps resolve the issue, you might want to consider breaking up the form submission into multiple requests or using AJAX to submit the data in chunks.

Remember to restart your web server and PHP-FPM service (if applicable) after making changes to configuration files to ensure the new settings take effect.

1 like
pcharitou's avatar

@LaryAI

Not sure why I'm replying to this but for anyone looking to help I was planning on breaking the submission to AJAX requests as suggested. This just seems like it shouldn't be necessary. I'd like to avoid it if possible.

Snapey's avatar

have you called phpinfo() from your controller to be sure that the settings you have changed are in place?

pcharitou's avatar

I didn't know I could check within the application like that - good to know, thank you!

It seems the settings are not in place, despite the server being restarted not long ago and restarting both fpm and nginx. Any idea how I could sync the changes?

Edit: If it makes a difference I have two versions of php installed on the server, 8.1 and 8.2 When I type php --ini in the shell it indicates it's using 8.2 (as does phpinfo() albeit more specifically it says 8.2.9). I haven't touched 8.1 and have only been editing 8.2 CLI and FPM .ini files

pcharitou's avatar

@Snapey I just looked, it's using the config file that I've been changing

Loaded Configuration File	/etc/php/8.2/fpm/php.ini
Scan this dir for additional .ini files	/etc/php/8.2/fpm/conf.d
Additional .ini files parsed	/etc/php/8.2/fpm/conf.d/10-mysqlnd.ini, /etc/php/8.2/fpm/conf.d/10-opcache.ini, /etc/php/8.2/fpm/conf.d/10-pdo.ini, /etc/php/8.2/fpm/conf.d/15-xml.ini, /etc/php/8.2/fpm/conf.d/20-bcmath.ini, /etc/php/8.2/fpm/conf.d/20-calendar.ini, /etc/php/8.2/fpm/conf.d/20-ctype.ini, /etc/php/8.2/fpm/conf.d/20-curl.ini, /etc/php/8.2/fpm/conf.d/20-dom.ini, /etc/php/8.2/fpm/conf.d/20-exif.ini, /etc/php/8.2/fpm/conf.d/20-ffi.ini, /etc/php/8.2/fpm/conf.d/20-fileinfo.ini, /etc/php/8.2/fpm/conf.d/20-ftp.ini, /etc/php/8.2/fpm/conf.d/20-gd.ini, /etc/php/8.2/fpm/conf.d/20-gettext.ini, /etc/php/8.2/fpm/conf.d/20-iconv.ini, /etc/php/8.2/fpm/conf.d/20-mbstring.ini, /etc/php/8.2/fpm/conf.d/20-mysqli.ini, /etc/php/8.2/fpm/conf.d/20-pdo_mysql.ini, /etc/php/8.2/fpm/conf.d/20-pdo_pgsql.ini, /etc/php/8.2/fpm/conf.d/20-pgsql.ini, /etc/php/8.2/fpm/conf.d/20-phar.ini, /etc/php/8.2/fpm/conf.d/20-posix.ini, /etc/php/8.2/fpm/conf.d/20-readline.ini, /etc/php/8.2/fpm/conf.d/20-shmop.ini, /etc/php/8.2/fpm/conf.d/20-simplexml.ini, /etc/php/8.2/fpm/conf.d/20-sockets.ini, /etc/php/8.2/fpm/conf.d/20-sysvmsg.ini, /etc/php/8.2/fpm/conf.d/20-sysvsem.ini, /etc/php/8.2/fpm/conf.d/20-sysvshm.ini, /etc/php/8.2/fpm/conf.d/20-tokenizer.ini, /etc/php/8.2/fpm/conf.d/20-xmlreader.ini, /etc/php/8.2/fpm/conf.d/20-xmlwriter.ini, /etc/php/8.2/fpm/conf.d/20-xsl.ini, /etc/php/8.2/fpm/conf.d/20-zip.ini

Everything loaded ^

Edit: I'm a little surprised because php --ini in the shell produces /etc/php/8.2/cli whereas phpinfo() says fpm so now I'm a bit confused. I keep the files consistently the same but I don't entirely understand why they conflict when checking

pcharitou's avatar

@Snapey Yes, curiously it seems most other fields other than max_input_vars have been updated. I can't recall if they're the default values or not as they've undergone a few changes but I don't think memory_limit starts at 2048M so I can only assume something very specific is interrupting max_input_vars specifically. I checked my application code for it and nothing though.

Tray2's avatar

You are not showing the interesting parts of the code, the form itself.

If the add rows, do they have the same names as the ones that already exists, or do they have different custom names?

If they are the same, make sure they use the array syntax in the markup.

Example:

<form method="POST">
  <input type="text" name="colors[]" value="red">
  <input type="text" name="colors[]" value="green">
  <input type="text" name="colors[]" value="blue">
  <input type="submit" value="Submit">
</form>
pcharitou's avatar

@Tray2 They do, the form fields are rather large and cumbersome but they follow the format as follows:

<input type="text" name="resource[1][field_type_1]">
<input type="text" name="resource[2][field_type_1]">
...
<input type="text" name="resource[200][field_type_1]">

Within the data dump I see no issues with the formatting of the array. Nor does it have any problems with the functionality of the rest of the application, it just gets cut off and acts as though the user never went past row 165

Please or to participate in this conversation.