POST vars suddenly not working through jQuery based AJAX calls

[jeffkee]

This has been happening since I migrated servers (upgraded to a dedicated server). It's an apache build with the standard stuff going on such as WHM and cPanel... and the PHP info can be found here: http://picnetbc.sonikastudios.com/admin/phpinfo.php

 

 

The AJAX calls, based on jQuery, were working fine for months (if not years) and suddenly they ALL stopped working, across all my accounts. You can imagine my panic.

 

The removefile function in javascript (jquery based) looks like this:

 

 function removefile(filename,folder,targetdiv) { // universal AJAX file removal function. folder MUST include '/' at the beginning for calls. 
    $.post('ajax_call_remove_file.php', {folder:folder, filename:filename },
        function(data){
            if(data=='1') {
            $('#'+targetdiv).html(filename+' has been successfully removed.');
            }
            else if(data=='0') {
            $('#'+targetdiv).html(filename+' is already removed - nothing more to remove.');
            }
        });
}

 

But for some reason, even though Firebug shows a successful registration of the POST vars being sent, the php file returns completely empty POSt vars. print_r($_POST) or print_r($_REQUEST) returns empty arrays in both cases. If I change the method to a GET mechanism it works - but I'd like to keep it at a POST variable.

 

Update: as per some help found on StackOverflow.com (which has failed me so far), I added these lines to the target .php file:

 

$input = file_get_contents('php://input');
var_dump($input);

 

And the target .php file returns the POST vars in a string format like this:

 

string(49) "folder=..%2Fcalendars%2F8&filename=attachment.pdf"

 

Which means that the data, in some form, is going through..

But the print_r($_POST) or print_r($_REQUEST) still returns a blank array like this:

 

array()

 

 

Also an Update:

I found another instance of a regular <form> with hidden fields not working - after submitting, it keeps going back to the pre-submit stage, as the $_POST['submit'] is not recognized. This is not AJAX - this is just a general submission form and it's choking on me. All this is happening across multiple accounts on my dedicated server, so I'm sure this is a PHP environment setting.

[gizmola]

I have never heard of anything that would effect the functionality of $_POST.  It is very simple.  Without seeing some code, it's hard to say what is going on.  Did you try a simple form posting to a simple script that displays the $_POST?

[jeffkee]

<?
include 'start.php';

$input = file_get_contents('php://input');
var_dump($input);
print_r($_REQUEST);

if(   [security check mechanism here, I removed it to protect my code]   )
{
if(file_exists($_REQUEST['folder'].'/'.$_REQUEST['filename']) && $_REQUEST['filename']!='') {
	unlink($_REQUEST['folder'].'/'.$_REQUEST['filename']);
	echo $_REQUEST['folder'].'/'.$_REQUEST['filename'];
} else {
	echo '0';
}
}

include 'ajax_close.php';
?>

 

The above is the code. I removed some parts that are security-related so as to not expose the security mechanisms..

 

Note that start.php contains db loading, the functions/classes loading so there's nothing that would override any POST or REQUEST vars etc.

 

The result is this:

 

string(49) "folder=..%2Fcalendars%2F8&filename=attachment.pdf"
Array
(
    [__utma] => 231166109.1211987303.1302262289.1302504386.1303496135.3
    [__utmz] => 231166109.1303496135.3.3.utmcsr=picnetbc.sonikastudios.com|utmccn=(referral)|utmcmd=referral|utmcct=/education-training
    [phpSESSID] => a7d90e55c74e4baa078137a8453e5fe5
)
0

 

 

I attached screenshots of what Firebug saw.

 

[attachment deleted by admin]

[gizmola]

Remove these lines:

 

$input = file_get_contents('php://input');
var_dump($input);

 

add

 

var_dump($_POST);

 

What do you get?

[jeffkee]

array(0) {
}

 

  I know bizarre. This is a code that's been working for years on multiple sites across my system.. this is happening after a server upgrade, and I just cannot figure it out, neither can my webhost. It's easy for us to say "the webhost should take care of it" but the folks here probably know a LOT more stuff than my webhost support team.. so thanks in advance.

[Alex]

What does start.php do?

[jeffkee]

loads db.php (database connection), classes.php (classes/functions used throughout the site), functions.php (other generic functions.. date display mechanisms etc.)  And it also has session_start(); in it.

[jeffkee]

To be more detailed:

 

<?
session_start();
include $_SERVER['DOCUMENT_ROOT'].'/db.php';
include $_SERVER['DOCUMENT_ROOT'].'/admin/settings.php';
include $_SERVER['DOCUMENT_ROOT'].'/admin/functions.php';
include $_SERVER['DOCUMENT_ROOT'].'/admin/classes.php';

ini_set('log_errors','On');
ini_set('error_log','error_log.txt');
ini_set('error_display','On');

// for now we keep the utf-8 encoding. BING maps preferrs UTF-8 for AJAX queries.
header('Content-Type: text/html; charset='.$encoding);

// caching prevention PHP script
header("Expires: Mon, 26 Jul 1990 05:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
?>

[Alex]

Strange..

 

What exactly did the server upgrade entail? Was the PHP version updated? If so, from what version?

 

For debugging purposes, you can try creating a new file that is completely blank besides printing out the POST data and seeing if you still have the problem with that file. That way you can rule out it being anything in your code that's causing this issue.

[jeffkee]

Most other POSt forms work save one. I cannot find the common denominator!!! This is driving me insane...

[Alex]

Maybe you can find a solution here. It seems like exactly you're experiencing, and even if that's not your specific problem there's a lot of discussion in the comments for other possible causes and solutions to those causes.

[jeffkee]

Thank you for that link!!! Encoding was not the issue, but based on the comments below, I figured out that the post_max_size was set to an invalid value. In the previous server I guess it was OK somehow. The core php.ini had it to 128M. My php.ini had it to 20000M (which was unnecessary, but since these apps are all used internally by website admins but not hte public, I had it set to that to make it practically unlimited).

 

I dropped it to 8M it worked. now I will experiment if I set the core php.ini to have 20000M, and see if it still works so I don't have to change the php.ini on each and every account.

 

Thank you!