This is quite strange, propably caused by bad design of the filter extension.

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?

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?

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.

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.

still a problem in 2018 on Versions:
5.6.30
7.1.10

Also this is a problem with the 7.3.0 release.

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!

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

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] <https://github.com/php/php-src/blob/php-7.4.22/main/SAPI.h#L242>
[2] <https://github.com/php/php-src/blob/php-7.4.22/sapi/cli/php_cli.c#L334-L337>
[3] <https://github.com/php/php-src/blob/php-7.4.22/main/SAPI.h#L263>
[4] <https://github.com/php/php-src/blob/php-7.4.22/sapi/cli/php_cli.c#L341-L359>