Description: ------------ I'm not sure whether this is within the realm of PHP_Compat, but it's something to consider... http://neosmart.net/blog/2006/100-apache-compliant-request_uri-for-iis-and-windows/ You don't actually need to impliment it as suggested, but the principles are the same.

Although it's not a PHP issue, it's an environment issue. Users have come to rely on $_SERVER['REQUEST_URI'], there should be a fall back in case it's not there as expected. This issue is mentioned many times: http://uk2.php.net/manual/en/reserved.variables.php#71239 http://bugs.php.net/bug.php?id=23114 http://bugs.php.net/bug.php?id=26825 http://bugs.php.net/bug.php?id=28410 It's always been denied as a PHP issue, however, it is something that PHP can handle.

Unless there are any complaints I will add this to the CVS. Thanks.

The reference for this appears in RFC2616 section 5.1.2 (http://tools.ietf.org/html/rfc2616#section-5.1.2) as "REQUEST-URI". It is clearly a HTTPD specification, but it has become a standard Apache HTTPD environment variable, which in turn has become a invaluable PHP environment variable. I'm not entirely sure when and how "REQUEST-URI" became a standard, but it is certainly used in that way. There is no reference to it in the Common Gateway Interface (CGI) Specification documentation on Environment Variables: http://hoohoo.ncsa.illinois.edu/cgi/env.html It is clearly a common issue when large/popular PHP software implements a function to tackle the issue: http://api.drupal.org/api/function/request_uri/6 Details of the REQUEST_URI are found here: http://php.net/reserved.variables.server With this in mind, I am on the understanding that PHP should support it, regardless of whether the HTTPD passes it or not. Unless there are any complaints I will add this as an environment compatibility.

Sounds ok to me, as long as it leaves REQUEST_URI alone if it's already set. It should probably also consider register_long_arrays and register_globals.

At revision: 301756 Note: I have considered register_long_arrays, but not register_globals since these are superglobals anyway.