www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - nginx reverse proxy for vibe tutorial

reply "James Miller" <james aatch.net> writes:
I have spent some time setting up nginx as a reverse proxy for 
vibe, and I thought I might share some of my issues here for now, 
just in case it helps someone.

I will assume that you are generally familiar with configuring 
nginx, where the files are, how server directives work etc.

The basic setup is the same as any other reverse proxy:

    server {
       listen 80;
       server_name dev.mysite.com;

       location / {
          proxy_pass http://localhost:8080/;
          proxy_redirect off;

          proxy_http_version 1.1;

          proxy_set_header   Host     $host;
          proxy_set_header   X-Real-IP        $remote_addr;
          proxy_set_header   X-Forwarded-For  
$proxy_add_x_forwarded_for;
          proxy_set_header   Content-Length   $body_bytes_sent;
       }
    }

The important things to note are that you need nginx version 
1.1.4 at least. Vibe doesn't seem to work correctly with HTTP 1.0 
requests in this configuration. Also, the line `proxy_set_header  
  Content-Length   $body_bytes_sent;` is necessary because vibe 
will wait for a body, for some reason when being proxied, this 
results in both nginx and vibe waiting for each other, with nginx 
eventually timing out. The Content-Length line sets the correct 
Content-Length for the request, allowing vibe to skip reading the 
body if it needs to.

I also have this section in my server config:


    location ~* 
^.+.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|r
f|js|woff|eof|ttf)$ 
{
       root /path/to/statics;
    }

which means that nginx serves the static files directly, skipping 
vibe. This seems like the best setup to me.

Things that should be improved are:

* More security! While this set up isn't actually insecure, I'm 
sure something could be done to make it better.
* using `try_files`, nginx complains that you can't use 
proxy_pass inside a named location (like ` vibe`), which means 
you can't use try_files to serve arbitrary static files, hence 
the massive list of extensions.

So far I'm loving vibe.d, it is fast and flexible and just works 
(mostly). With nginx serving the static files out the front, the 
speed of the setup is incredible.

I hope that people find this helpful.

--
James Miller
May 04 2012
next sibling parent reply David <d dav1d.de> writes:
 * using `try_files`, nginx complains that you can't use proxy_pass
 inside a named location (like ` vibe`), which means you can't use
 try_files to serve arbitrary static files, hence the massive list of
 extensions.


why not doing:


root /path/to/static

location / {
     try_files $uri  app_proxy
}

location  app_proxy {
     ...
}
May 04 2012
parent reply "James Miller" <james aatch.net> writes:
On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:

 * using `try_files`, nginx complains that you can't use 
 proxy_pass
 inside a named location (like ` vibe`), which means you can't 
 use
 try_files to serve arbitrary static files, hence the massive 
 list of
 extensions.


 why not doing:


 root /path/to/static

 location / {
     try_files $uri  app_proxy
 }

 location  app_proxy {
     ...
 }


I tried that, nginx complained endlessly about it. I'm not sure 
why and I would prefer to use that version.

Also, I need to make an adjustment to my configuration, the 
$body_bytes_sent doesn't work the way I thought, so you actually 
need to do

server {
    ...
    proxy_set_body $request_body;
    ...
    // Remove proxy_set_header Content-length... line
}
May 05 2012
parent reply David <d dav1d.de> writes:
Am 06.05.2012 03:00, schrieb James Miller:

 On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:

 * using `try_files`, nginx complains that you can't use proxy_pass
 inside a named location (like ` vibe`), which means you can't use
 try_files to serve arbitrary static files, hence the massive list of
 extensions.


 why not doing:


 root /path/to/static

 location / {
 try_files $uri  app_proxy
 }

 location  app_proxy {
 ...
 }


 I tried that, nginx complained endlessly about it. I'm not sure why and
 I would prefer to use that version.

 Also, I need to make an adjustment to my configuration, the
 $body_bytes_sent doesn't work the way I thought, so you actually need to do

 server {
 ...
 proxy_set_body $request_body;
 ...
 // Remove proxy_set_header Content-length... line
 }


Well this works perfectly for me (not with vibe, with gunicorn)
May 06 2012
parent reply "James Miller" <james aatch.net> writes:
On Sunday, 6 May 2012 at 13:47:27 UTC, David wrote:

 Am 06.05.2012 03:00, schrieb James Miller:

 On Friday, 4 May 2012 at 11:54:04 UTC, David wrote:

 * using `try_files`, nginx complains that you can't use 
 proxy_pass
 inside a named location (like ` vibe`), which means you 
 can't use
 try_files to serve arbitrary static files, hence the massive 
 list of
 extensions.


 why not doing:


 root /path/to/static

 location / {
 try_files $uri  app_proxy
 }

 location  app_proxy {
 ...
 }


 I tried that, nginx complained endlessly about it. I'm not 
 sure why and
 I would prefer to use that version.

 Also, I need to make an adjustment to my configuration, the
 $body_bytes_sent doesn't work the way I thought, so you 
 actually need to do

 server {
 ...
 proxy_set_body $request_body;
 ...
 // Remove proxy_set_header Content-length... line
 }


 Well this works perfectly for me (not with vibe, with gunicorn)


I thought it should work, and I'm probably missing something, but 
here:

nginx: [emerg] "proxy_pass" cannot have URI part in location 
given by regular expression, or inside named location, or inside 
"if" statement, or inside "limit_except" block in 
/etc/nginx/conf/nginx.conf:87
nginx: configuration file /etc/nginx/conf/nginx.conf test failed

Thats what I get at the "Checking configuration stage".

For the record, using a named section works perfectly for my php 
configuration section, so I'm wondering if its something to with 
proxy_pass?

--
James Miller
May 06 2012
parent reply "James Miller" <james aatch.net> writes:
On Sunday, 6 May 2012 at 22:32:16 UTC, James Miller wrote:

 I thought it should work, and I'm probably missing something, 
 but here:

 nginx: [emerg] "proxy_pass" cannot have URI part in location 
 given by regular expression, or inside named location, or 
 inside "if" statement, or inside "limit_except" block in 
 /etc/nginx/conf/nginx.conf:87
 nginx: configuration file /etc/nginx/conf/nginx.conf test failed

 Thats what I get at the "Checking configuration stage".

 For the record, using a named section works perfectly for my 
 php configuration section, so I'm wondering if its something to 
 with proxy_pass?

 --
 James Miller


Well a bit of googling reveals this annoying problem:

using `proxy_pass http://localhost:8080/;` is an error, where
using `proxy_pass http://localhost:8080;` is fine.

I think FUUUUUUUUUU is the most appropriate sentiment here.

For the record: the most recent, working, version of the
configuration is. Its also more flexible and secure, which is
nice.


        server {
	listen		80;
	server_name	vibe.mysite.com;

	location / {
		root /path/to/statics;
		try_files $uri  vibe;
	}

	location  vibe {
		proxy_pass http://localhost:8080;
		proxy_redirect     off;

		proxy_pass_request_body on;
		proxy_http_version 1.1;

		proxy_set_body $request_body;

		proxy_set_header   Host             $host;
		proxy_set_header   X-Real-IP        $remote_addr;
		proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
	}
        }
May 06 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 6 May 2012 at 22:42:21 UTC, James Miller wrote:

 I think FUUUUUUUUUU is the most appropriate sentiment here.


Wait till you try using conditional blocks in Lighty's 
configuration files… [1]

David


[1] lighttpd supports conditional blocks for a number of 
predefined variables, including http host, … – but only 
evaluates the first (or was it: last?) one of a kind, and 
silently discards the other ones. Especially funny if you use a 
Debian-style configuration where configuration is split over a 
number of files (conf-available/conf-enabled directories).
May 06 2012
parent reply "James Miller" <james aatch.net> writes:
On Sunday, 6 May 2012 at 22:50:56 UTC, David Nadlinger wrote:

 On Sunday, 6 May 2012 at 22:42:21 UTC, James Miller wrote:

 I think FUUUUUUUUUU is the most appropriate sentiment here.


 Wait till you try using conditional blocks in Lighty's 
 configuration files… [1]

 David


 [1] lighttpd supports conditional blocks for a number of 
 predefined variables, including http host, … – but only 
 evaluates the first (or was it: last?) one of a kind, and 
 silently discards the other ones. Especially funny if you use a 
 Debian-style configuration where configuration is split over a 
 number of files (conf-available/conf-enabled directories).


I think I remember that from when I was running Lighty, it seemed 
awesome at first, then quickly became a nightmare to manage.

Yeah, I went Apache -> Lighttpd -> nginx for webservers, nginx is 
definitely the best so far. Not as many features as Apache, but I 
find it suitable, and (F)CGI is plenty fast enough using a local 
socket.

--
James Miller
May 06 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"James Miller" <james aatch.net> wrote in message 
news:tsqxxnxrqfcfyvxmpzhg forum.dlang.org...

 On Sunday, 6 May 2012 at 22:50:56 UTC, David Nadlinger wrote:

 On Sunday, 6 May 2012 at 22:42:21 UTC, James Miller wrote:

 I think FUUUUUUUUUU is the most appropriate sentiment here.


 Wait till you try using conditional blocks in Lighty's configuration 
 files. [1]

 David


 [1] lighttpd supports conditional blocks for a number of predefined 
 variables, including http host, . - but only evaluates the first (or was 
 it: last?) one of a kind, and silently discards the other ones. 
 Especially funny if you use a Debian-style configuration where 
 configuration is split over a number of files 
 (conf-available/conf-enabled directories).


 I think I remember that from when I was running Lighty, it seemed awesome 
 at first, then quickly became a nightmare to manage.

 Yeah, I went Apache -> Lighttpd -> nginx for webservers, nginx is 
 definitely the best so far. Not as many features as Apache, but I find it 
 suitable, and (F)CGI is plenty fast enough using a local socket.


I guess I must have never gotten as fancy with Apache as other people have, 
but when I went Apache -> Nginx, my thought was "Wait a minute...I thought 
people said Nginx was less feature-rich than Apache."

Maybe I just don't wear the sysadmin hat enough, but I've never come across 
anything I needed to do in Apache that I couldn't do in Nginx (assuming a 
version of Nginx compiled with all the official bells and whistles). It even 
supports directory listings, which [pleasantly] surprised me. And 
URL-rewriting in Nginx doesn't make my brain hurt, which is a nice change :)
May 07 2012
prev sibling parent zjh <fqbqrr 163.com> writes:
谢谢!
Feb 22 2017