Unexpected value of $request_uri in an SSI subrequest

Hello all,

It seems that the $request_uri in a location used by a ssi virtual
subrequest is set to the location that issue the SSI call, whereas the
$uri is the value of the SSI subrequest URL.
I don’t know if this is a bug or a wanted behaviour

In this dummy test case this is not relevant, but with memcache and
using $request_uri to generate the key, this make an infinite loop.

Here is a dummy configuration to test :

location / {
ssi on;
set $memcached_key $request_uri;
default_type text/html;
memcached_pass 10.0.0.177:11211;
error_page 404 = @cache_miss;
error_page 502 = @cache_miss;
}

location /test/ {
return 404;
}

location ~ “/head/([0-9]{1,})/” {
#rewrite (.) /test/?$uri;
rewrite (.
) /test/?$request_uri;
}

  • Using rewrite (.*) /test/?$request_uri args: are set to the location
    “/”:
    2009/04/20 07:34:49 [notice] 32342#0: *1 rewritten data: “/test/”,
    args: “/webstats/2009/4/”, client: 10.0.0.177, server: dummy.net,
    request: “GET /webstats/2009/4/ HTTP/1.0”

  • Using rewrite (.*) /test/?$uri args: are set to the location “/
    head…” as expected:
    2009/04/20 07:35:57 [notice] 32494#0: *1 rewritten data: “/test/”,
    args: “/head/69/”, client: 10.0.0.177, server: dummy.net, request:
    “GET /webstats/2009/4/ HTTP/1.0”

Regards,

xav