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|rtf|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

> * 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 {
    ...
}

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
}

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)

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

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;
	}
       }

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).

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

"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 :)

谢谢!