I'm running into an issue where large data sets sent over POST using AJAX are not making it to the $_POST variable in PHP.

The user uploads an Excel/CSV file through a webform and is parsed via AJAX. This particular example has 775 records with 13 fields/elements each. Adding additional fields being submitted and there are less than 11,000 elements in the dataset. From the research I've done on the subject, 32-bit browsers (i.e. Firefox, Chrome, etc.) should be able to handle 4.29 billion elements, so I don't see the data size as an issue, especially as the response from the file upload contains all the elements.

The issue only rears its head when the entire form is submitted to be validated and entered into the database. The issue is that the console on both Firebug and Chrome Developer Tools shows that the whole data set is submitted:

Doing a var_dump on the $_POST gives this:

The php.ini has 'post_max_size' set to 200M. Even 'upload_max_filesize' is set to 100M. This issue occurs in both Firefox 32.0.3 and Chrome 37.0.2062.103 m that I have tested personally and other older versions (including IE 10) that UAT has tested.

The AJAX call is:

new wrapper.ajax('/t1.php', {
    type: 'POST',
    data: data,
    form: $('form[name=oppForm]'),
    success: function (response)
    {
    if (response.result)
    {
        window.location = response.result;
    }
    },
    complete: function ()
    {
    $("#submit").loading('done');
    }
});

The PHP is:

<?php
var_dump($_POST);

Any thoughts?

EDIT

After talking with some other developers, I also checked the output of php://input and found that it DID contain the entire POST data that the browsers were sending, but that the data was not getting translated into $_POST properly. However, it does work properly if I remove 10 keys from the post data, and submit 765 instead of 775.

I'm running into an issue where large data sets sent over POST using AJAX are not making it to the $_POST variable in PHP.

The user uploads an Excel/CSV file through a webform and is parsed via AJAX. This particular example has 775 records with 13 fields/elements each. Adding additional fields being submitted and there are less than 11,000 elements in the dataset. From the research I've done on the subject, 32-bit browsers (i.e. Firefox, Chrome, etc.) should be able to handle 4.29 billion elements, so I don't see the data size as an issue, especially as the response from the file upload contains all the elements.

The issue only rears its head when the entire form is submitted to be validated and entered into the database. The issue is that the console on both Firebug and Chrome Developer Tools shows that the whole data set is submitted:

Doing a var_dump on the $_POST gives this:

The php.ini has 'post_max_size' set to 200M. Even 'upload_max_filesize' is set to 100M. This issue occurs in both Firefox 32.0.3 and Chrome 37.0.2062.103 m that I have tested personally and other older versions (including IE 10) that UAT has tested.

The AJAX call is:

new wrapper.ajax('/t1.php', {
    type: 'POST',
    data: data,
    form: $('form[name=oppForm]'),
    success: function (response)
    {
    if (response.result)
    {
        window.location = response.result;
    }
    },
    complete: function ()
    {
    $("#submit").loading('done');
    }
});

The PHP is:

<?php
var_dump($_POST);

Any thoughts?

EDIT

After talking with some other developers, I also checked the output of php://input and found that it DID contain the entire POST data that the browsers were sending, but that the data was not getting translated into $_POST properly. However, it does work properly if I remove 10 keys from the post data, and submit 765 instead of 775.

• javascript
• php
• ajax
• post

• 5 Also check max_input_vars and max_input_nesting_level (the latter should be less important in your case though). And also check if f.e. suhosin is used to run your PHP code, that has additional limits regarding security of incoming data. – C3roe Commented Oct 7, 2014 at 16:08
• If running on Apache, there is also limitrequestbody to consider. – naneau Commented Oct 7, 2014 at 16:09
• 1 A fellow developer suggested I look at the difference between "php://input" and $_POST. ?php file_put_contents('/tmp/zelda4.log', print_r(file_get_contents("php://input"), true)); file_put_contents('/tmp/zelda5.log', print_r($_POST, true)); And the "php://input" does contain the whole expected contents that the browsers are stating they sent, but $_POST is still not showing all of it. – Scott T Rogers Commented Oct 7, 2014 at 16:24
• First off, I might suggest that your POST is extremely inefficient. Why send the column headers for each row if you can just do it once and re-assemble server-side? I don't know if this is the problem you're running into, but if it were me, I'd re-think how the data is getting POSTed. I might also consider parsing the CSV server-side. – Brad Commented Oct 7, 2014 at 18:46
• var_dump($_POST['data']); – Harutyun Abgaryan Commented Oct 7, 2014 at 18:46

1 Answer 1

The issue ended up being that 'max_input_vars' in the php.ini file was not set high enough. The value was set to 10,000 and the user was submitting data of near 11k, thus some of it was getting truncated. Changing this value to be greater is what solved the issue.