在 Win32 平台上使用 Visual C 构建 nginx
先决条件
要在 Microsoft Win32® 平台上构建 nginx,您需要:
- Microsoft Visual C编译器。已知 Microsoft Visual Studio® 8 和 10 可以正常工作。
- MSYS。
- 如果您要构建 OpenSSL® 和有 SSL 支持的 nginx,则需要 Perl。例如 ActivePerl 或 Strawberry Perl。
- Mercurial 客户端
- PCRE、zlib 和 OpenSSL 库源代码。
构建步骤
在开始构建之前,确保将 Perl、Mercurial 和 MSYS 的 bin 目录路径添加到 PATH 环境变量中。从 Visual C 目录运行 vcvarsall.bat 脚本设置 Visual C 环境。
构建 nginx:
- 启动 MSYS bash。
- 检出 hg.nginx.org 仓库中的 nginx 源代码。例如:
hg clone http://hg.nginx.org/nginx
- 创建一个 build 和 lib 目录,并将 zlib、PCRE 和 OpenSSL 库源码解压到 lib 目录中:
mkdir objs
mkdir objs/lib
cd objs/lib
tar -xzf ../../pcre-8.41.tar.gz
tar -xzf ../../zlib-1.2.11.tar.gz
tar -xzf ../../openssl-1.0.2k.tar.gz
- 运行 configure 脚本:
auto/configure --with-cc=cl --builddir=objs --prefix= \
--conf-path=conf/nginx.conf --pid-path=logs/nginx.pid \
--http-log-path=logs/access.log --error-log-path=logs/error.log \
--sbin-path=nginx.exe --http-client-body-temp-path=temp/client_body_temp \
--http-proxy-temp-path=temp/proxy_temp \
--http-fastcgi-temp-path=temp/fastcgi_temp \
--with-cc-opt=-DFD_SETSIZE=1024 --with-pcre=objs/lib/pcre-8.41 \
--with-zlib=objs/lib/zlib-1.2.11 --with-openssl=objs/lib/openssl-1.0.2k \
--with-select_module --with-http_ssl_module
- 运行 make:
nmake -f objs/Makefile
相关内容
原文档
http://nginx.org/en/docs/howto_build_on_win32.html
转换重写规则
重定向到主站点
使用共享主机的用户以前仅使用 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 规则
典型的 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;
}
原文档
http://nginx.org/en/docs/http/converting_rewrite_rules.html
WebSocket 代理
要将客户端与服务器之间的连接从 HTTP/1.1 转换为 WebSocket,可是使用 HTTP/1.1 中的 协议切换 机制。
然而,有一个微妙的地方:由于 Upgrade
是一个逐跳(hop-by-hop)头,它不会从客户端传递到代理服务器。当使用转发代理时,客户端可以使用 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 帧以重置超时并检查连接是否仍然活跃。