Re: Changes to SuperGlobals for PHP 8 (was: something about session_start...)
| From: | Rowan Collins | Date: | Sat, 29 Jul 2017 16:52:19 +0000 |
| Subject: | Re: Changes to SuperGlobals for PHP 8 (was: something about session_start...) | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100107@lists.php.net to get a copy of this message | ||
On 29 July 2017 15:05:57 BST, Andrea Faulds <ajf@ajf.me> wrote:
>Hi Rowan,
>
>Rowan Collins wrote:
>> On a slight tangent, I consider $_SERVER to be a broken pile of
>"we'll just shove this in here and hope for the best", and I will
>oppose any attempt to convert it into an object which doesn't
>reorganize its keys to be sane, documented, and as cross-platform as
>the SAPI layer can make it. :P
>
>$_SERVER makes sense to me, its content is what the CGI environment
>variables would be (or are, if you're actually using CGI in 2017).
>Those
>are standardised.
But what does a standardised CGI variable list have to do with anything when you're running
under an Apache module, or one of our two fast-cgi SAPIs, let alone if we ever want event-based or
asynchronous SAPIs to be a thing?
If you want to know the URL the user requested, you have to know about the subtle differences
between half a dozen different variables which will be populated differently, or not at all,
depending on your configuration. Some of this is inevitable because there are too many different
ways of achieving the same thing, but at least some of it is known by the SAPI, which nonetheless
blindly populates $_SERVER with whatever the hosting server provided.
And talking of name mangling, CGI mangles the request HTTP headers in its own quirky way, when they
should just be a structure of their own separate from this generic environment. That particular
quirk can even cause security problems, IIRC.
Regards,
--
Rowan Collins
[IMSoP]