What can nullify $_POST variable?

Question

I'm transferring files using http post request from one host to another. Receiving host runs apache with php onboard. The request contains multipart/form-data and is performing by php script (cURL). There are 86 files with total size about 20Mb. The issue is the receiving php script gots empty $_POST array. I reconfigured sending script so it sends the same request in loop but removes one file from data collection on each iteration. When 36 files (total size ~12Mb) are removed the receiving script accepts the data, $_POST variable is populated well. What can be wrong? I've reviewed all resposible php.ini parameters, so they contain reasonable values.

  ini_set("post_max_size","510M"); 
  ini_set("memory_limit","400M"); 
  ini_set("upload_max_filesize","510M"); 
  ini_set("max_file_uploads","500");

Is there a way to investigate the reason? I mean, error_log doesn't contain anything useful. Maybe there is another source to see?

Maybe [max_input_time](http://www.php.net/manual/en/info.configuration.php#ini.max-input-time) — Ron van der Heijden, Jan 14 '13 at 09:13
first of all check if your settings were any effect with `phpinfo() `under `local value` column — Your Common Sense, Jan 14 '13 at 09:13
yeah, I've checked. all php.ini params are applied. $_FILES variable is also empty. $_REQUEST and php://input are empty as well. — heximal, Jan 14 '13 at 09:19
@heximal I think I know what the issue is, will post up in a mo — Ben Carey, Jan 14 '13 at 09:24
Both transferring and receiving scripts execute on Windows environment. — heximal, Jan 14 '13 at 09:30
PHP does process form fields in the order they're sent. If the file field is the first thing in your form, and the file exceeds the size limit, then processing will abort before any of the other fields are handled. Try moving the file field to the bottom of the form and see what happens. — axel.michel, Jan 14 '13 at 09:30
`post_max_size` and `upload_max_filesize` can be changed in [PHP_INI_PERDIR](http://php.net/manual/en/configuration.changes.modes.php); `max_file_uploads` can be changed in PHP_INI_SYSTEM. — Salman A, Jan 14 '13 at 09:57

score 3 · Accepted Answer · edited May 23 '17 at 10:30

The post_max_size value cannot be set at runtime on a per-directory basis. Even though your phpinfo() will reflect the change, it will be ignored when a form is processed and will therefore revert back to the default of 8MB.

This is proved by the fact that the total size of your files is 20MB, yet when you remove ~12MB of files, the script works.

20 - 12 = 8MB // Therefore the script works

The only solution for this is to set the value in the php.ini, or alternatively as you are using Apache, you can set the value in an http.conf or .htaccess file.

I too had this issue a while ago, although it was on Windows running IIS. However, the issue is still the same. For more information on the issue please see this thread.

As it turns out, on Windows, you can only set ini directives that are marked PHP_INI_USER per directory. Unfortunately, upload_max_filesize and post_max_size are both PHP_INI_PERDIR. From the PHP docs at http://php.net/manual/en/configuration.changes.php

The settings for the directory would be active for any script running from this directory or any subdirectory of it. The values under the key should have the name of the PHP configuration directive and the string value. PHP constants in the values are not parsed. However, only configuration values changeable in PHP_INI_USER can be set this way, PHP_INI_PERDIR values can not.

So even though Plesk has an interface to change those directives, and even though phpinfo() picks up on them, they do nothing to change the actual max upload sizes. Plesk should not allow you to change those on Windows, and phpinfo() should not report the change, but what can you do.

Thanks for very detailed answer. Unfortunately it didn't help. I tried modify php.ini with restarting apache, tried to specify these params within .htaccess - no effect. Maybe there is some restriction on transferring side? e.g. on cURL — heximal, Jan 14 '13 at 11:16
no errors. it looks like absolutely valid http request, but with no post data. no php warnings, notices, errors produced. all error_levels are set to maximum - error_reporting(E_ALL) — heximal, Jan 14 '13 at 11:41
@heximal Please forgive the stupid question, but have you got `display_errors` turned one, along with error logging? — Ben Carey, Jan 14 '13 at 11:42
@heximal Have you tried changing all the settings in the php.ini? And also checking the `phpinfo()` to ensure the changes have been registered? — Ben Carey, Jan 14 '13 at 11:59
yes, all values is configured with php.ini as well, phpinfo() confirms it. I'm really out of ideas — heximal, Jan 14 '13 at 12:38

score 1 · Answer 2 · answered Jan 14 '13 at 09:15

1

Check if you have the Suhosin extension installed. It has several settings that limit the amount of data you can receive via, POST, GET and REQUEST. Also, it can limit the number of files that are uploaded through the setting suhosin.upload.max_uploads which defaults to 20.

When the settings take actions, the POST array is usually truncated.

Also, if you are uploading files, check the $_FILES array, not $_POST.

answered Jan 14 '13 at 09:15

chiborg

26,978
14
97
115

no, unfortunately, this suggestion is wrong - nothing exotic is installed – heximal Jan 14 '13 at 09:20
1

suhosin is neither exotic nor something needs to be installed separately - it's just a part of most PHP distributions – Your Common Sense Jan 14 '13 at 09:26
Ok, will bear in mind. I heard about it but never faced before. – heximal Jan 14 '13 at 09:31

What can nullify $_POST variable?

2 Answers2