php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66978 $_SERVER['REQUEST_URI'] does not contain the request's complete URI
Submitted: 2014-03-28 22:45 UTC Modified: 2014-04-01 06:49 UTC
From: chealer at gmail dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: Irrelevant OS:
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: chealer at gmail dot com
New email:
PHP Version: OS:

 

 [2014-03-28 22:45 UTC] chealer at gmail dot com
Description:
------------
According to http://www.php.net/manual/en/reserved.variables.server.php the REQUEST_URI entry of $_SERVER contains "The URI which was given in order to access this page".

As reported in #55780, this is not the case, as the example given just after shows: "for instance, '/index.html'". Actually, REQUEST_URI contains a URI reference.

This bug exists since as far as I can remember. At this point, it is probably a bad idea to simply fix. This should probably be treated as a documentation bug, and just cause the $_SERVER documentation to fix the entry description, adding a warning about the name.

However, having the actual request URI would be useful too, be it through a new "ACTUAL_REQUEST_URI" entry, a function, or something.

Note: this bug is not completely PHP-specific. http://labs.apache.org/webarch/uri/rfc/rfc3986.html#hierarchical gives a historical perspective on URI/URL terminology.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-03-28 22:56 UTC] rasmus@php.net
-Status: Open +Status: Not a bug
 [2014-03-28 22:56 UTC] rasmus@php.net
It is not a question of fixing it. PHP has nothing to do with setting the REQUEST_URI in most cases. This is a $_SERVER variable and is set by the server. For some edge-case SAPIs we do set it, but for the most common ones this is set by the server so if you think it is set wrong when you are running mod_php under Apache, for example, then you need to file a bug with Apache.
 [2014-03-31 05:39 UTC] chealer at gmail dot com
Servers don't magically set PHP variables. PHP may base a variable's value on data provided by a server, but the problem remains an interpreter bug as long as a bug in the server hasn't been identified. I don't see which bug should be filed against Apache here.

In any case, to make progress, let's start with the documentation. Have the documentation reflect how PHP is supposed to behave, and I'll deal with eventual behavioral bugs after.
 [2014-03-31 06:51 UTC] rasmus@php.net
So you are suggesting we rewrite the REQUEST_URI set by the server? Sorry, that is not going to happen. This is a CGI environment variable which the web server passes to downstream applications. We have to trust it and provide it as-is to PHP applications.
 [2014-04-01 06:49 UTC] chealer at gmail dot com
CGI doesn't specify REQUEST_URI. It may be an *environment* variable, but the only reason to keep its value as-is would be to respect convention.

That being said, PHP has offered a stable REQUEST_URI for over a decade. It would be a big backwards-incompatible change to ignore the past. I do not think that change is worth the cost at this point.

As I wrote:
"This should probably be treated as a documentation bug, and just cause the $_SERVER documentation to fix the entry description, adding a warning about the name.

However, having the actual request URI would be useful too, be it through a new "ACTUAL_REQUEST_URI" entry, a function, or something."
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 27 20:01:29 2024 UTC