Member Avatar for tedkurtz

I ran into a situation which suggests to me that there is a limit to the number of input text boxes you can have in an HTML form. I'm developing a registration system for a sports event and wanted a form which would allow the organizers to edit several items for each entrant. I had one hidden input with the entrant's ID and two text-box inputs for the items I wanted to edit. I found that this wouldn't work for more than approximately 333 entrants. I tried one hidden input (ID) and one text-box input and found that it wouldn't work for more than approximately 498 entrants. In each case that is approximately 1000 inputs. I use the POST method to transfer the inputs.

I'm using PHP to process the submitted form, and the PHP program runs only if I observe the limit.

I've Googled around and have found some discussion along this line, and those claiming to be in the know say that that there is no limit for the POST method.

Any thoughts?

TedK

  • 4 Contributors
  • 3 Replies
  • 130 Views
  • 3 Hours Discussion Span
  • Latest Post Latest Post by sheikhali449

Dani AI

Generated

— the "about 1000 inputs" symptom strongly points to PHP's input-variable limit rather than the POST method itself. PHP's max_input_vars defaults to 1000 and any form fields beyond that are ignored (so the script never sees them). See the PHP manual for max_input_vars for details: max_input_vars docs.

Practical fixes:

  • Raise max_input_vars in php.ini (or in .htaccess for mod_php, or in .user.ini / FPM pool config for PHP-FPM) and restart the web server. Example php.ini settings:

    ; php.ini
max_input_vars = 3000
post_max_size = 16M

    Also confirm post_max_size so the total POST body is allowed: post_max_size docs.

  • If changing server settings is not possible, submit the entrant data as one payload instead of thousands of separate fields. For example, POST a JSON blob (counts as one input variable) and decode it server-side:

    $data = json_decode(file_get_contents('php://input'), true);

Operational notes and alternatives:

  • Check phpinfo() to see the effective max_input_vars and whether a hardening extension (Suhosin) is present; Suhosin can impose its own suhosin.post/request.max_vars limits.
  • 's timeout angle can still matter for very large uploads — check max_input_time and max_execution_time and server logs if requests are being killed.
  • 's UX advice is sound: consider per-record editing, batch CSV uploads, or chunked/AJAX submissions. These improve validation, user experience, and avoid hitting server limits altogether.

Quick check: a small phpinfo() page (<?php phpinfo(); ?>) will confirm which limits are active and where to change them.

Recommended Answers

All 3 Replies

Member Avatar for JameB

Could be that the information from the 1000 inputs is taking too much time to transfer and the process is killed due to exceeding the time limit.

One temporary solution would be to break the pages into two or three or however many pages, with each page having ~1000 inputs.
.
.
.
.
Just wondering though, why do you need that many inputs anyways?! Do you think people will enter 500 people at the same time?

Edited by JameB
Member Avatar for almostbob

not the ideal way to handle multiple inputs or multiple users
example, 100 entrants = 400x3 'invalid form data' messages if the form is validated, or 400 users created to blank values if the form is not validated
most input is done one record at a time
multiple updates can be better handled with a specific form to update table

Edited by almostbob
Member Avatar for sheikhali449

reaching the limit is not a piece of cake though

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.