Describe you feature request

The values are somewhat documented here: https://www.php.net/manual/en/reserved.variables.server.php

Specifically, this issue is in regards to:

REQUEST_URI:
The URI which was given in order to access this page; for instance, '/index.html'.

SCRIPT_NAME:
Contains the current script's path. This is useful for pages which need to point to themselves. The FILE constant contains the full path and filename of the current (i.e. included) file.

PHP_SELF:
The filename of the currently executing script, relative to the document root. For instance, $_SERVER['PHP_SELF'] in a script at the address http://example.com/foo/bar.php would be /foo/bar.php. The FILE constant contains the full path and filename of the current (i.e. included) file. If PHP is running as a command-line processor this variable contains the script name.

Which suggests a 'literal', non-processed URI for REQUEST_URI. Digging into the comments on this page, I was able to get a little more information from people studying these behaviors of these variables across time/SAPIs (I love comments on these pages).

REQUEST_URI:

• should include query parameters
• before any rewriting (e.g., raw URL after the domain, as the user typed it)
• includes leading slash

SCRIPT_NAME:

• filename of the entry point script (e.g., index.php; should be constructable by removing DOCUMENT_ROOT from PHP_SELF)
• excludes PATH_INFO
• excludes query parameters

PHP_SELF:

• URL after all rewrites and processing
• includes PATH_INFO
• excludes query parameters

I also noted that we may not have the correct values for PATH_INFO:

PATH_INFO:
Contains any client-provided pathname information trailing the actual script filename but preceding the query string, if available. For instance, if the current script was accessed via the URI http://www.example.com/php/path_info.php/some/stuff?foo=bar, then $_SERVER['PATH_INFO'] would contain /some/stuff.

This should be the values after the php script: /index.php/some/path should be /some/path, different from REQUEST_URI.

Apache and Nginx

For Apache and nginx, I looked into how they handle encoded urls (urls that have %2f instead of /):

Apache has AllowEncodedSlashes to process these urls. It looks like the typical usecase is something like: /example/http:%2F%2Fwww.someurl.com/ for proxies and potentially retrieving screenshots. Apache considers these invalid urls unless this setting is set to On or NoDecode (and processes them or doesn't, depending on the value of this setting).

For nginx, it depends on how you formulate the variable in your configuration. If you use $uri, then it will pass on the unescaped version, but $request_uri will be the original escaped version. Looking at the default fastcgi parameters that came with my nginx installation (ubuntu 24.04), it sets REQUEST_URI to $request_uri.

In both SAPIs, this behavior is configurable for handling url-decoding before passing to PHP.