Unexpected value of $request_uri in an SSI subrequest.

Mon Apr 20 09:46:24 MSD 2009

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.

<html>
<!--# include virtual="/ssi/$userid/" -->
</html>

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