Why does this line return null in my live server?
filter_input(INPUT_SERVER, 'REQUEST_METHOD');
The live server is php5.5.9
Have I missed something?
I thought it is used to replace the global method below?
$_SERVER['REQUEST_METHOD'];
some of the code,
public function __construct()
{
// Construct other generic data.
$this->clientRequestMethod = filter_input(INPUT_GET, 'method'); // such as list, add, update, etc
$this->clientPostMethod = filter_input(INPUT_POST, 'method'); // such as update
$this->serverRequestMethod = filter_input(INPUT_SERVER, 'REQUEST_METHOD'); //such as get or post
}
public function processEntry()
{
// Determine the $_SERVER['REQUEST_METHOD'] whether it is post or get.
if ($this->serverRequestMethod === 'POST' && $this->clientPostMethod != null)
{
$this->processPost();
}
else if($this->serverRequestMethod === 'GET' && $this->clientRequestMethod != null)
{
$this->processRequest();
}
}
So the problem/bug is this:
filter_input() doesn't work with INPUT_SERVER or INPUT_ENV when you use FASTCGI
The bug has been known for years and I found nothing saying it was addressed. I found several work-arounds but no complete solution so I plopped the best work-around into this helper function for a project-wide solution. To provide some level of security and avoid train wrecks, the function falls back to filter_var() where filter_input() fails. It uses the same format as the native filter_input() function for easy integration into projects and easy future removal should the bug ever be fixed.
function filter_input_fix ($type, $variable_name, $filter = FILTER_DEFAULT, $options = NULL )
{
$checkTypes =[
INPUT_GET,
INPUT_POST,
INPUT_COOKIE
];
if ($options === NULL) {
// No idea if this should be here or not
// Maybe someone could let me know if this should be removed?
$options = FILTER_NULL_ON_FAILURE;
}
if (in_array($type, $checkTypes) || filter_has_var($type, $variable_name)) {
return filter_input($type, $variable_name, $filter, $options);
} else if ($type == INPUT_SERVER && isset($_SERVER[$variable_name])) {
return filter_var($_SERVER[$variable_name], $filter, $options);
} else if ($type == INPUT_ENV && isset($_ENV[$variable_name])) {
return filter_var($_ENV[$variable_name], $filter, $options);
} else {
return NULL;
}
}
This seems the best solution. Please let me know if it contains errors that might cause issues.
I had the same problem where it was working on my local machine (OSX Mavericks, PHP version 5.4.24) and not on my live server (Cent OS 5). I upgraded the server from 5.3.9 to 5.5.15 (and added the mb and mcrypt functions although that's probably irrelevant) and now it works.
This probably isn't helpful if you're on a shared host but you could ask them if they can rebuild PHP/Apache.
I was having the same issue in my XAMPP localhost as well and was looking for solutions madly. What I ended up with, it is a known PHP bug for this function if you are running the PHP in FCGI mode (FCGI/PHP 5.4 in my case). I was confirmed going through this link.
The workaround I used is to filter_var($_SERVER['PHP_AUTH_USER'], FILTER_SANITIZE_STRING) but this is not an alternative of filter_input. filter_input is more secure.
FastCGI seems to cause strange side-effects with unexpected null values when using INPUT_SERVER and INPUT_ENV with this function. You can use this code to see if it affects your server.
If you want to be on the safe side, using the superglobal $_SERVER and $ENV variables will always work. You can still use the filter* functions for Get/Post/Cookie without a problem, which is the important part!
Source: http://php.net/manual/es/function.filter-input.php#77307
I solve it changing my php.ini from:
variables_order = "GPCS"
To:
variables_order = "GPCSE"
By default PHP wasn't registering the environment variables, so this change enabled them. The interesting is that the INPUT_SERVER variables came back to work too!
Just two addiotional informations, i am using PHP 7.0.13 and as said in other answers, this issue is related to a PHP bug.
Another option is use the following:
filter_var(getenv('REQUEST_METHOD'));
