Uncaught Whoops\Exception\ErrorException: Undefined index: _SERVER

[magnus-eriksson]

Anytime my application throws an error (undefined variable or function, on exceptions etc), Whoops PrettyPageHandler shows me a pretty page (like it should) but the error is always the same. It's in the PrettyPageHandler itself.

Uncaught Whoops\Exception\ErrorException: Undefined index: _SERVER in /var/.../vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php:666 Stack trace: #0 /var/.../vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php(666): Whoops\Run->handleError(8, 'Undefined index...', '/var/www/enstar...', 666, Array) #1 /var/.../vendor/filp/whoops/src/Whoops/Handler/PrettyPageHandler.php(242): Whoops\Handler\PrettyPageHandler->masked('_SERVER') #2

The error occurs on row 666 (of course :)) in the PrettyPageHandler class:

    private function masked($superGlobalName) {
        $blacklisted = $this->blacklist[$superGlobalName];
        $values = $GLOBALS[$superGlobalName];     <--- /// Row 666, where it breaks
 
        foreach($blacklisted as $key) {
            if (isset($values[$key])) {
                $values[$key] = str_repeat('*', strlen($values[$key]));
            }
        }
        return $values;
    }

This error happens in both version 2.1.6 and 2.1.7. It looks like the new blacklist feature was added in 2.1.6 and is the root of the problem.

I'm running PHP 7.1.1 on Ubuntu

[staabm]

could you elaborate why the superglobal $_SERVER is not defined in your stack?

[magnus-eriksson]

I have a standard PHP 7.1.1 install and am not doing anything specific. I am actually using $_SERVER in my code (my router uses it, for example), with no issues. The PrettyPageHandle-page even shows me the correct content of $_SERVER so it does exist.

[staabm]

ok, different question: is $GLOBALS['_SERVER'] defined in your env?

[magnus-eriksson]

For some reason, no. $GLOBALS only contains _GET, _POST, _FILES and _COOKIE. I did a var dump in a new file without loading anything else, so there's no code messing with it.
When I switch to PHP 7.0, it looks correct.

[staabm]

hmmm could you take a diff of your php.ini's used between 7.0/7.1

[magnus-eriksson]

I can't seem to find any diff that has any relation to this issue, though.
Here's the diffs: https://www.diffchecker.com/yb4A8ymT

[staabm]

hmm not sure whats differnt in your env. per 3v4l the SERVER array should be available across PHP-version
https://3v4l.org/9rlB6

[magnus-eriksson]

It appears to be xdebug that does something. In the 7.1-version, the xdebug module wasn't enabled (not even loaded). After enabling it, it all works. This seems... wrong?

[staabm]

@derickr is this something you are aware of? does xdebug influence $GLOBALS ?

[derickr]

No, it shouldn't do that. And I'm also not aware of it. Do you have a small reproducible case?

[magnus-eriksson]

I just tested in PHP 7.0, and even on another server with PHP 5.5.9 (just as a reference). None of them has $GLOBALS['_SERVER'], $GLOBALS['_REQUEST'] or $GLOBALS['_ENV'] without having xdebug enabled.

You should be able to reproduce it by simply do a var_dump($GLOBALS) and disable/enable xdebug.

[derickr]

Oh, I read this the other way around! I thought you said that Xdebug removed something.

I think it's because of this: https://github.com/xdebug/xdebug/blob/master/xdebug.c#L1033 — but I don't know whether that is still required in PHP 7.x.

[derickr]

@magnus-eriksson Can you try this Xdebug patch? http://derickrethans.nl/files/dump/globals.patch.txt

[magnus-eriksson]

@derickr It's when xdebug isn't enabled the $GLOBALS array are missing those keys that the PrettyPage handler is trying to use . When xdebug is enabled, they exist and everything works, so I'm not sure that patching a module that isn't even loaded would help much.

It simply seems like this is how PHP works (even back in version 5). I've never used $GLOBALS myself so it was new for me.

My suggestion would be to do one of the following:

• Add xdebug as a dependency for the library (or at least add a note about it in the docs) and keep the code as is
• Add a simple check $values = isset($GLOBALS[$superGlobalName]);
• Don't depend on $GLOBALS but rather use the super globals (like $_SERVER etc) directly and make it more compatible.

As it is right now, the library seems to depend on xdebug to be enabled, even though the same result could be produced without it.

[derickr]

I realise that, but Xdebug should also not create these keys if it is loaded. That means we both have to fix something. Do you have something small for me to try to reproduce the Xdebug issue?

And then you should also change your code so that it doesn't rely on the SERVeR key yo be there

[magnus-eriksson]

@derickr You can try my suggestion above to reproduce it: Simply do a var_dump($GLOBALS) and disable/enable xdebug.

[derickr]

This makes little sense. PHP should always set $GLOBALS['_SERVER']['SCRIPT_NAME'] for example. In which environment are you trying this?

FWIW, I can't reproduce this.

[magnus-eriksson]

@derickr I've tried it on Ubuntu 16.04 with PHP 7.0 and 7.1, with a standard LAMP stack, as well as on Ubuntu 14.04 with PHP 5.5, also with a standard LAMP stack. All showed the same behaviour.

With xdebug enabled (xdebug.so loaded), $GLOBALS contained all the global variables and with the xdebug.so commented out, only _POST, _GET, _FILES and _COOKIE was set in the $GLBOALS array.

I checked it by doing a var_dump($GLOBALS) in a new file without anything else loaded.

[derickr]

So are you saying you don't have a $GLOBALS['_SERVER']['SCRIPT_NAME'] with an empty php.ini ? It really is always there on the CLI here - Xdebug loaded or not:

derick@singlemalt:~ $ pe 7.0dev
[PHP: 7.0.18-dev  ]
derick@singlemalt:~ $ php -n -r 'var_dump(array_keys($GLOBALS)); var_dump( $GLOBALS['_SERVER']['SCRIPT_NAME'] );'
array(8) {
  [0]=>
  string(4) "_GET"
  [1]=>
  string(5) "_POST"
  [2]=>
  string(7) "_COOKIE"
  [3]=>
  string(6) "_FILES"
  [4]=>
  string(4) "argv"
  [5]=>
  string(4) "argc"
  [6]=>
  string(7) "_SERVER"
  [7]=>
  string(7) "GLOBALS"
}
string(1) "-"

And the same for PHP 5.5.38 and 7.1.2.

[magnus-eriksson]

@derickr I see why you can't reproduce it. You're running it through CLI and I'm running it through Apache. If I'm running your script through cli, I get the same as you.

Just now, I downloaded Ubuntu 16.04.2 Server from ubuntu.com and installed it as a new VM. I selected Ubuntu's LAMP-stack during install. Did a sudo apt-get update && sudo apt-get upgrade to get the latest versions. No modifications to php.ini, no extra libraries installed. xdebug does not seem to be installed by default either.

PHP Version

PHP 7.0.15-0ubuntu0.16.04.4

Content of index.php

<?php
echo "<pre>";
var_dump(array_keys($GLOBALS)); var_dump( $GLOBALS['_SERVER']['SCRIPT_NAME'] );

Output

array(5) {
  [0]=>
  string(4) "_GET"
  [1]=>
  string(5) "_POST"
  [2]=>
  string(7) "_COOKIE"
  [3]=>
  string(6) "_FILES"
  [4]=>
  string(7) "GLOBALS"
}
NULL

As you can see, _SERVER is still not present when using Apache on a default Ubuntu 16.04 LAMP setup, which are pretty common.

[derickr]

Apparently: https://bugs.php.net/bug.php?id=65223

In Xdebug I force the parser to notice with the calls to zend_is_auto_global_str in the patch.

[magnus-eriksson]

So this looks like an example of "It's not a bug, it's a feature". :-)

I would say that the conclusion would be that you should not count on $GLOBALS['_SERVER'] to be present and that the PrettyPage-handler should check if it is present, before trying to use it. Alternatively make a note of it in the docs, and maybe not add it in a patch release?

[derickr]

Right, but it doesn't explain why it is different on the CLI... and I still ought to fix the Xdebug part of it :-)

[staabm]

@magnus-eriksson please double check this fix #486

[magnus-eriksson]

@staabm It's tested and confirmed to solve the issue.

[denis-sokolov]

Fixed in #486, released as 2.1.8. Thank you for your report, and thank you for working so closely with us and helping us debug the problem, @magnus-eriksson!

[magnus-eriksson]

@denis-sokolov No problem. That's what Open Source is all about. You've made a great library and I'm just grateful to be able to help. :) Thank you for sorting it out quickly!

[denis-sokolov]

You did not imply it directly, but here's for the benefit of future readers: @filp is the original author. I am but a long-term maintainer.