# SSI fails when the source is a proxy with a variable

**URL:** <https://www.ruby-forum.com/t/ssi-fails-when-the-source-is-a-proxy-with-a-variable/194725>\
**Category:** NGINX\
**Created:** [September 9, 2010, 4:36pm UTC](https://www.ruby-forum.com/t/ssi-fails-when-the-source-is-a-proxy-with-a-variable/194725 "2010-09-09T16:36:26Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Shish](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f08c70/32.png) [@Shish](https://www.ruby-forum.com/u/Shish)\
**Post date:** [September 9, 2010, 4:36pm UTC](https://www.ruby-forum.com/t/ssi-fails-when-the-source-is-a-proxy-with-a-variable/194725/1 "2010-09-09T16:36:26Z")

</div>

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](http://dev-server.mydomain.com) and [www.mydomain.com](http://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](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](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](http://127.0.0.1):$proxy\_port;}

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

Posted at Nginx Forum:

> **[SSI fails when the source is a proxy with a variable](https://forum.nginx.org/read.php?2,128804,128804#msg-128804)**
>
> 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...

---

<div class="post-metadata">

**Author:** ![Shish](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f08c70/32.png) [@Shish](https://www.ruby-forum.com/u/Shish)\
**Post date:** [September 9, 2010, 7:49pm UTC](https://www.ruby-forum.com/t/ssi-fails-when-the-source-is-a-proxy-with-a-variable/194725/2 "2010-09-09T19:49:06Z")

</div>

Hello!

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

> port 5080  
> 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](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](http://127.0.0.1):$proxy\_port;}

Try something like this:

- location / {proxy\_pass [http://127.0.0.1](http://127.0.0.1):$proxy\_port;}

- location / {proxy\_pass [http://127.0.0.1](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 D.