|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #49184 INPUT_SERVER returns NULL for set variables (CLI)
Submitted: 2009-08-06 21:48 UTC Modified: 2021-08-05 11:13 UTC
Avg. Score:4.3 ± 0.8
Reproduced:74 of 75 (98.7%)
Same Version:40 (54.1%)
Same OS:41 (55.4%)
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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: m dot kurzyna at crystalpoint dot pl
New email:
PHP Version: OS:


 [2009-08-06 21:48 UTC] m dot kurzyna at crystalpoint dot pl
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:



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

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-07 10:20 UTC]
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_NAME <==> 0x9B9D269A
PHP_SELF <==> 0xBD55DE96
DOCUMENT_ROOT <==> 0x1DB85847
DOCUMENT_ROOT <==> 0x1DB85847
SCRIPT_NAME <==> 0x9B9D269A
PHP_SELF <==> 0xBD55DE96

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:


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


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 

                       $_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 
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:
 [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'));

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

PHP 7.3.11, macOS X, Laravel Valet development web-server
 [2021-08-05 11:13 UTC]
-Type: Bug +Type: Documentation Problem
 [2021-08-05 11:13 UTC]
Each SAPI can set up additional $_SERVER variables by implementing
the respective hook[1].  The cli SAPI, for instance, adds all
environment variables to $_SERVER[2].  The filter extension,
however, does not use $_SERVER, because it may have been modified
by userland code. Instead it offers another hook for SAPIs[3], so
these can register variables to be available via INPUT_SERVER.
The cli SAPI only registers five variables with the filter
extension[4].  I don't know why it has been designed this way, but
obviously we can't change it at this point in time for BC reasons.
Thus, we should fix the documentation, which is indeed misleading.

[1] <>
[2] <>
[3] <>
[4] <>
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 16 12:01:28 2024 UTC