SSI fails when the source is a proxy with a variable

[Maxim Dounin]

Hello!

On Thu, Sep 09, 2010 at 10:34:53AM -0400, Shish wrote:

> I have two pylons processes running on my devbox, one is my app in
> production mode, one in development mode -- I have
> dev-server.mydomain.com and www.mydomain.com both aliased to the devbox.
> Rather than have the nginx config duplicated once for each domain, I
> have one config with an if statement in it. Thus, in my config file is
> this:
> 
> if ($http_host ~ "(dev-server)") {set $proxy_port 5000;} # dev mode =
> port 5000
> if ($http_host !~ "(dev-server)") {set $proxy_port 5080;} # live mode =
> port 5080
> location / {proxy_pass http://127.0.0.1:$proxy_port;}
> 
> So far, so good.
> 
> But now, I want to make use of SSIs, so I stick "ssi on;" at the top of
> this server {} block -- trying it, it doesn't work: when I request
> /ssi-test which simply includes /include1 ("hello") and /include2
> ("world"), nginx actually just keeps fetching /ssi-test recursively and
> inserting it into itself until I kill the backend process.
> 
> So why did I mention my proxy setup? Well, it seems that this bug only
> appears when proxy_pass has a variable in it. If I proxy to a static
> server, ie "proxy_pass http://127.0.0.1:5000;" (no variable), SSIs work
> perfectly -- but this means I have to edit the config file and reload
> nginx to flick between dev and production views :-(
> 
> I have also tried removing the ifs and just having
> 
> set $proxy_port 5000;
> location / {proxy_pass http://127.0.0.1:$proxy_port;}

Try something like this:

- location / {proxy_pass http://127.0.0.1:$proxy_port;}
+ location / {proxy_pass http://127.0.0.1:$proxy_port$uri$is_args$args;}

> but this doesn't work either, which suggests that it is the variable
> rather than the if statements that are the trigger.

nginx use original request uri ($request_uri) if one isn't 
specified in proxy_pass with variables, and this doesn't play well 
with ssi subrequests.

Maxim Dounin