|  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
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
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-2023 The PHP Group
All rights reserved.
Last updated: Mon Oct 02 00:01:24 2023 UTC