Bug #49184 [Com]: INPUT_SERVER returns NULL for set variables (CLI)

From: Date: Tue, 28 Oct 2014 14:40:39 +0000
Subject: Bug #49184 [Com]: INPUT_SERVER returns NULL for set variables (CLI)
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-188344@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=49184&edit=1

 ID:                 49184
 Comment by:         cb at lathspell dot de
 Reported by:        m dot kurzyna at crystalpoint dot pl
 Summary:            INPUT_SERVER returns NULL for set variables (CLI)
 Status:             Verified
 Type:               Bug
 Package:            Filter related
 Operating System:   *
 PHP Version:        5.*, 6 (2009-08-07)
 Block user comment: N
 Private report:     N

 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------
[2014-02-05 12:55:52] 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?

------------------------------------------------------------------------
[2011-02-01 23:19:12] 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?

------------------------------------------------------------------------
[2009-08-07 10:20:34] jani@php.net

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

------------------------------------------------------------------------
[2009-08-06 21:48:51] 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"


------------------------------------------------------------------------



--
Edit this bug report at https://bugs.php.net/bug.php?id=49184&edit=1


Thread (10 messages)

« previous php.bugs (#188344) next »