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
