Bug or intent?: $request_uri in SSI

When including a file with SSI that has a query string, the $uri and
$query_string variables are set to the included file. However, the
$request_uri variable remains set to the original file. Is this supposed
to
happen, or should $request_uri change?

An example follows, just be sure to change “root
/Users/larry/Sites/ngingx_request_uri/html;” to point to your local
copy.
Once you have created these files, go to
http://127.0.0.1:8084/example.html?page=1


nginx.conf

worker_processes 1;
events {
worker_connections 256;
}

http {
server {
listen 8084;

    location / {
      ssi on;

      default_type text/html;

      root /Users/larry/Sites/ngingx_request_uri;
    }
}

}


example.html

$request_uri with SSI

From example.html

$request_uri: :: $uri: :: $query_string:


fragment.inc

From fragment.inc

$request_uri: :: $uri: :: $query_string:

Shouldn't $request_uri be "/fragment.inc?page=1"?

After re-reading the documentation page (
http://wiki.codemongers.com/NginxHttpCoreModule#var_request_uri), it
turns
out that “$request_uri” is indeed supposed to be the original request:
“$request_uri, this variable is equal to the complete initial URI
together
with the arguments;”

Is there a variable like “$request_uri” that applies to the current
request?
If not, the alternative is an “if statement” that checks to see whether
“$query_string” has a value. If it does, use $uri?$query_string,
otherwise
use $uri.

Larrytheliquid wrote:

otherwise use $uri.
$is_args evaluates to “?” or “” depending on whether $args is set. Try:

$uri$is_args$args

Evan