|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45566 Strict comparision on $_SERVER values fail
Submitted: 2008-07-19 20:43 UTC Modified: 2010-06-21 00:31 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: samuel at slbdata dot se Assigned:
Status: Wont fix Package: Strings related
PHP Version: 6CVS-2008-07-19 (snap) OS: Ubuntu 8.04.1
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: samuel at slbdata dot se
New email:
PHP Version: OS:


 [2008-07-19 20:43 UTC] samuel at slbdata dot se
Comparing a string in the $_SERVER superglobal using the strict equality operator (===) always fails, even though both types are strings. $_GET and other variables work fine.

I'm using the php.ini-recommended file, with no changes except for display_(startup_)errors which are enabled. My locale is sv_SE.UTF-8 (the LANG environment variable is set to this value)

This used to work fine in php6.0-200804260630

Reproduce code:

echo "Type is: ".gettype($rm)." <br />\n";
if (($rm !== 'GET') && ($rm == 'GET')) {
  echo "Bug! <br />\n";
} else {
  echo "Correct behaviour! <br />\n";

echo "Type is: ".gettype($sp)." <br />\n";
if (($sp !== 'HTTP/1.1') && ($sp == 'HTTP/1.1')) {
  echo "Bug! <br />\n";
} else {
  echo "Correct behaviour! <br />\n";

Expected result:
Type is: string
Correct behaviour! 
Type is: string
Correct behaviour! 

Actual result:
Type is: string
Type is: string


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-22 22:33 UTC]
Try var_dump() on those variables.
 [2008-07-23 09:15 UTC] samuel at slbdata dot se
$str = 'Test';
echo "<br />\n";

echo "<br />\n";

echo "<br />\n";

That code gives me:

unicode(4) "Test"
string(3) "GET"
string(8) "HTTP/1.1"

So the problem is that $_SERVER variables are binary strings? The HTTP specification says that all request methods are US-ASCII encoded (RFC 2616 section 5.1.1) so at least REQUEST_METHOD should be safe to convert to unicode.

From the HTTP spec:

CHAR           = <any US-ASCII character (octets 0 - 127)>
token          = 1*<any CHAR except CTLs or separators>
Method                = "OPTIONS"                ; Section 9.2
                      | "GET"                    ; Section 9.3
                      | "HEAD"                   ; Section 9.4
                      | extension-method
extension-method = token
 [2008-07-23 10:16 UTC] samuel at slbdata dot se
I looked through the HTTP specification to see which $_SERVER values are US-ASCII encoded and which values are not. These values are always US-ASCII encoded and can be converted to unicode (section in HTTP spec. in parantesis):

SERVER_PROTOCOL (section 3.1)
HTTP_ACCEPT_CHARSET (section 14.2)
HTTP_CONNECTION (section 14.10)

URLs are encoded according to RFC 2396 and can't contain any non-ASCII characters. So HTTP_HOST, REQUEST_URI and QUERY_STRING are also safe.


The other HTTP values may contain ISO-8859-1 characters and characters from other encodings if they are RFC 2047 encoded (see TEXT in section 2.2).

I guess the path values like PHP_SELF use should use the encoding in unicode.filesystem_encoding, but I don't really know how Unicode in PHP works so I could be wrong.
 [2008-07-23 11:50 UTC] samuel at slbdata dot se
I think that I forgot SCRIPT_NAME. It's part of the URL so it must be an ASCII string too (and can be converted to Unicode).

If the behaviour of PHP is changed to use Unicode values, then some functions that work with URLs need to be updated to use Unicode too. For example, the urlencode/urldecode function. See bug 45602
 [2010-06-21 00:31 UTC]
-Status: Open +Status: Wont fix
 [2010-06-21 00:31 UTC]
Old trunk related.
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Mon Oct 21 07:01:27 2019 UTC