php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49184 INPUT_SERVER returns NULL for set variables (CLI)
Submitted: 2009-08-06 21:48 UTC Modified: 2009-08-07 10:20 UTC
Votes:70
Avg. Score:4.3 ± 0.9
Reproduced:66 of 67 (98.5%)
Same Version:40 (60.6%)
Same OS:38 (57.6%)
From: m dot kurzyna at crystalpoint dot pl Assigned:
Status: Verified Package: Filter related
PHP Version: 5.*, 6 (2009-08-07) OS: *
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2009-08-06 21:48 UTC] m dot kurzyna at crystalpoint dot pl
Description:
------------
This is very similar to #44779, however my report regards variables set as environment variables when running CLI.

A variable is visible in $_SERVER but INPUT_SERVER returns NULL. Setting via SetEnv in apache and when running as mod_php is fine.

Reproduce code:
---------------
<?php

var_dump(
        filter_input(INPUT_SERVER,'ENV_NAME',FILTER_SANITIZE_STRING),
        $_SERVER['ENV_NAME']
);

?>



Expected result:
----------------
$ ENV_NAME=var php /tmp/t.php
string(3) "var"
string(3) "var"


Actual result:
--------------
$ ENV_NAME=var php /tmp/t.php
NULL
string(3) "var"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-07 10:20 UTC] jani@php.net
This is quite strange, propably caused by bad design of the filter extension.
 [2011-02-01 23:19 UTC] mjk at emmjaykay dot org
Looking at the filter_input() call in filter.c:747 on 5.3.5, it looks like the call to zend_hash_find() fails.

(gdb) call zend_hash_display(input->value->ht)
SCRIPT_FILENAME <==> 0x537C323A
SCRIPT_NAME <==> 0x9B9D269A
PATH_TRANSLATED <==> 0x3A4E2C63
PHP_SELF <==> 0xBD55DE96
DOCUMENT_ROOT <==> 0x1DB85847
DOCUMENT_ROOT <==> 0x1DB85847
PATH_TRANSLATED <==> 0x3A4E2C63
SCRIPT_FILENAME <==> 0x537C323A
SCRIPT_NAME <==> 0x9B9D269A
PHP_SELF <==> 0xBD55DE96
(gdb) 

So I guess ENV_NAME never gets put in there at all?
 [2014-02-05 12:55 UTC] jpswade at gmail dot com
It seems this bug still appears in PHP v5.4.24 and has done for over 6 years:

* http://www.php.net/manual/en/function.filter-input.php#77307

The general advice is "do not access superglobal $_server array directly" and the solution is to use the filter_input() function instead.

* http://stackoverflow.com/questions/19767894/warning-do-not-access-superglobal-post-array-directly-on-netbeans-7-4-for-ph

However, this is a show stopper as you can't fully follow this through because all of the INPUT_SERVER variables return NULL.

Is PHP serious about not accessing superglobals directly or is this incorrect advice?
 [2014-10-28 14:40 UTC] cb at lathspell dot de
If you don't care about fixing this bugs for *years*, please be at least so kind to document that it is "not intended" to be used from CLI.
 [2017-01-23 07:44 UTC] dclarke at blastwave dot org
Still a valid bug in 5.6.30 :

bash-4.3$ ./php-5.6.30_SunOS5.10_sparcv9.001/sapi/cli/php --version
PHP 5.6.30 (cli) (built: Jan 23 2017 01:16:31) 
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
bash-4.3$  cat  foo_var_dump.php 
<?php

var_dump(
          filter_input(INPUT_SERVER,'SOME_ENV_NAME',
                       FILTER_SANITIZE_STRING),
                       $_SERVER['SOME_ENV_NAME'] );

?>
bash-4.3$ SOME_ENV_NAME=this_stuff ./php-5.6.30_SunOS5.10_sparcv9.001/sapi/cli/php foo_var_dump.php 
NULL
string(10) "this_stuff"

It may be worth running a trace through the calls and I did build 
with full debug sysmbols so this is possible. At least on Solaris.
 [2018-01-12 19:43 UTC] m dot patrushev at pitanik dot de
still a problem in 2018 on Versions:
5.6.30
7.1.10
 [2018-12-11 20:48 UTC] zoon01 at xigmanas dot com
Also this is a problem with the 7.3.0 release.
 [2020-05-07 19:01 UTC] alexinbeijing at gmail dot com
Is this as simple as I think it is...?

filter_input() can pull variables from several different "groups", which you can choose using INPUT_GET, INPUT_POST, INPUT_SERVER, INPUT_ENV, and so on.

Looking at the source code for the PHP interpreter, it looks like environment variables are not accessed with INPUT_SERVER but rather INPUT_ENV. Actually, if you run the repro code using INPUT_ENV, it works.

Probably people assumed that the variables in $_SERVER should be accessible using INPUT_SERVER. It seems that's not the case.

The documentation seems to be faulty, in that it doesn't explain what variables can actually be accessed through INPUT_SERVER. I can see some of them in the source code for the interpreter, like "PHP_AUTH_USER", "PHP_AUTH_PW", "PHP_AUTH_DIGEST", "REQUEST_TIME_FLOAT", "REQUEST_TIME", and so on. You can also get "SCRIPT_NAME", "SCRIPT_FILENAME", "DOCUMENT_ROOT", etc.

Looking in Google, the Internet seems to be half covered with erroneous statements  that filter_input(INPUT_SERVER, ...) doesn't work. I wonder why nobody ever stepped in to explain?

If I'm off base, please straighten me out!
 [2020-05-29 23:06 UTC] progr-d at yandex dot ru
var_dump(filter_input(INPUT_SERVER, 'SERVER_NAME'));
var_dump($_SERVER['SERVER_NAME']);

Result
------
string(0) ""
string(13) "tmp.localhost"


PHP 7.3.11, macOS X, Laravel Valet development web-server
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sat Oct 31 11:01:24 2020 UTC