Yes, and that's my plan exactly. The only reason I need to listen on two separate ports for each site is that each site caches its content independently, which means that nginx has to be able to look for the cached content and server that up without ever touching Rails. So, for two sites to be able to each have a cached index.html file (as well as static image files), I have to have a site-specific path in each server directive.<br>
<br>For instance, consider the following:<br><br> server {<br> listen 80;<br> server_name <a href="http://site-a.com">site-a.com</a> *.<a href="http://site-a.com">site-a.com</a>; # needs to be site-specific<br>
root /var/www/site-a;<br> location / {<br> # serve static files<br> if (-f $document_root$uri.html) {<br> rewrite (.*) $1.html break;<br> break;<br> }<br> # serve cached pages directly<br>
if (-f $document_root/../../../current/tmp/cache/content/site-a/$uri.html) {<br> rewrite (.*) $document_root/../../../current/tmp/cache/content/site-a/$1.html break;<br> }<br> }<br> }<br><br>
I realize I could set the root to "/var/www" (and drop the "/site-a"), then use the $host or $http_host variable in my static/cache paths, but my CMS supports *.domain.com-style vhosts, which can't be represented on the file system. If I drop the *.domain.com-style vhost support, then I could have paths like /var/www/<a href="http://site-a.com">site-a.com</a> with symlinks pointing to it (like /var/www/<a href="http://www.site-a.com">www.site-a.com</a> -> /var/www/<a href="http://site-a.com">site-a.com</a>).<br>
<br>Even if I could figure out a good way to represent this on the file system, the CMS (and my nginx config for serving static and cached content) supports serving different files for a request to the same site based on the requested host. This is useful (and is actually being used) for a company with multiple locations that wants a site tailored to each location. For instance, when you request <a href="http://site-a.com">site-a.com</a>, you see the home page with the address and phone number for the company's primary location in the header. Requesting <a href="http://site-b.com">site-b.com</a> shows the exact same home page except that the header now has the address and phone number for the company's secondary location. Similarly, a slightly different logo image can be served for <a href="http://site-b.com">site-b.com</a>, even though both images are at /images/logo.gif. As such, simply symlinking /var/www/<a href="http://site-b.com">site-b.com</a> to point to /var/www/<a href="http://site-a.com">site-a.com</a> would break this functionality.<br>
<br>I still think the original solution will work -- I'll just have to have two server directives on the back-end nginx for each site (one for http, and one for https). This isn't a problem, as this is how it works now -- only now, the backend nginx uses server_name to choose the proper server directive whereas with the new solution it will use an internal IP and port number to do the same thing.<br>
<br>Nick<br><br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 4:40 PM, Rob Schultz <span dir="ltr"><<a href="mailto:lists@ruby-forum.com">lists@ruby-forum.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well with this setup (which i thought you were looking for from the<br>
first article) you can put as many frontend slices as you need which can<br>
support 5 IP addresses each for 5 https sites. You only need the two<br>
listen directives on the back end nginx to allow it to manually set the<br>
X_FORWARDED_PROTO so your rails will know which type of connection it<br>
came from.<br>
<div><div></div><div class="Wj3C7c">--<br>
Posted via <a href="http://www.ruby-forum.com/" target="_blank">http://www.ruby-forum.com/</a>.<br>
<br>
</div></div></blockquote></div><br>