Apache .htaccess与Nginx rewrite转换

只使用Apache的.htaccess文件配置一切的人,通常将如下的规则:

RewriteCond  %{HTTP_HOST}  example.org
RewriteRule  (.*)          http://www.example.org$1

转换为类似这样的东西:

server {
    listen       80;
    server_name  www.example.org  example.org;
    if ($http_host = example.org) {
        rewrite  (.*)  http://www.example.org$1;
    }
    ...
}

这是错误的、冗长的、低效的方式,正确的方式是为example.org定义一个单独的服务器:

server {
    listen       80;
    server_name  example.org;
    return       301 http://www.example.org$request_uri;
}

server {
    listen       80;
    server_name  www.example.org;
    ...
}

在0.9.1版本之前,重定向指令为:
rewrite ^ http://www.example.org$request_uri?;

另一个例子,是相反的“颠倒”逻辑,“所有不是example.com和www.example.com”:

RewriteCond  %{HTTP_HOST}  !example.com
RewriteCond  %{HTTP_HOST}  !www.example.com
RewriteRule  (.*)          http://www.example.com$1

应该简单的定义example.com, www.example.com以及“其他”:

server {
    listen       80;
    server_name  example.com www.example.com;
    ...
}

server {
    listen       80 default_server;
    server_name  _;
    return       301 http://example.com$request_uri;
}

在0.9.1版本前,重定向方法如下:
rewrite ^ http://example.com$request_uri?;

转换规则

典型的Mongrel规则:

DocumentRoot /var/www/myapp.com/current/public

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L]

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ $1 [QSA,L]

RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html [QSA,L]

RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ $1.html [QSA,L]

RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

应该转为:

location / {
    root       /var/www/myapp.com/current/public;

    try_files  /system/maintenance.html
               $uri  $uri/index.html $uri.html
               @mongrel;
}

location @mongrel {
    proxy_pass  http://mongrel;
}

nginx代理WebSocket

为了将客户端和服务器之间的连接从HTTP/1.1转为WebSocket,协议切换机制在HTTP/1.1中可以使用。
由于“Upgrade”是一个逐跳头,它不会从客户端传递给被代理服务器。客户端可以使用CONNECT方法避免这个问题。但这个不能够在反向代理中工作,因为客户端不知道任何代理服务器,代理服务器必须进行特殊处理。

从1.3.13版本起,nginx实现了特殊的操作模式,允许当被代理服务器返回101状态码(切换协议)时,在客户端和被代理服务器之间建立一个通道,客户端通过请求头中的“Upgrade”要求一个协议切换。

如上所说,逐跳头包括“Upgrade”和“Connection”不会从客户端传递到被代理服务器,因此为了使被代理服务器知道客户端打算切换协议到WebSocket,这些头必须显式的传递:

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}

一个更复杂的例子,到被代理服务器的请求“Connection”头域的值取决于客户端请求头出现的“Upgrade”字段:

http {
    map $http_upgrade $connection_upgrade {
        default upgrade;
        ''      close;
    }

    server {
        ...

        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }

默认情况下,如果被代理服务器在60秒内没有传输任何数据,连接将被关闭。这个超时时间可以通过proxy_read_timeout指令增加。或者,被代理服务器可以配置成周期性的发送WebSocket ping帧来重置超时时间,并检测连接是否仍然存活。