Edit report at http://bugs.php.net/bug.php?id=45566&edit=1
ID: 45566 Updated by: fel...@php.net Reported by: samuel at slbdata dot se Summary: Strict comparision on $_SERVER values fail -Status: Open +Status: Wont fix Type: Bug Package: Strings related Operating System: Ubuntu 8.04.1 PHP Version: 6CVS-2008-07-19 (snap) New Comment: Old trunk related. Previous Comments: ------------------------------------------------------------------------ [2008-07-23 11:50:01] 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 ------------------------------------------------------------------------ [2008-07-23 10:16:14] 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_ENCODING (section 14.3) 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. SERVER_PORT, REMOTE_PORT, HTTP_KEEP_ALIVE, GATEWAY_INTERFACE seem to be safe to convert too ;) 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 09:15:25] samuel at slbdata dot se <?php $str = 'Test'; var_dump($str); echo "<br />\n"; $rm = $_SERVER['REQUEST_METHOD']; var_dump($rm); echo "<br />\n"; $sp = $_SERVER['SERVER_PROTOCOL']; var_dump($sp); 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-22 22:33:30] j...@php.net Try var_dump() on those variables. ------------------------------------------------------------------------ [2008-07-19 20:43:38] samuel at slbdata dot se Description: ------------ 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: --------------- <?php $rm = $_SERVER['REQUEST_METHOD']; echo "Type is: ".gettype($rm)." <br />\n"; if (($rm !== 'GET') && ($rm == 'GET')) { echo "Bug! <br />\n"; } else { echo "Correct behaviour! <br />\n"; } $sp = $_SERVER['SERVER_PROTOCOL']; 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 Bug! Type is: string Bug! ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/bug.php?id=45566&edit=1