Mercurial > hg > nginx-site

changeset 558:149f54c158f0

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Added initial translation in simplified Chinese submitted by the Server Platforms Team at Taobao.com.
author Ruslan Ermilov <ru@nginx.com>
date Thu, 28 Jun 2012 10:27:07 +0000
parents 654096219aba
children 522fcab2c6f1
files GNUmakefile xml/cn/GNUmakefile xml/cn/docs/debugging_log.xml xml/cn/docs/faq.xml xml/cn/docs/howto.xml xml/cn/docs/http/configuring_https_servers.xml xml/cn/docs/http/converting_rewrite_rules.xml xml/cn/docs/http/request_processing.xml xml/cn/docs/http/server_names.xml xml/cn/docs/index.xml xml/cn/docs/introduction.xml xml/cn/docs/sys_errlist.xml xml/cn/docs/welcome_nginx_facebook.xml xml/cn/docs/windows.xml xml/cn/index.xml xml/i18n.xml xml/menu.xml
diffstat 17 files changed, 1825 insertions(+), 6 deletions(-) [+]
line wrap: on
line diff
--- a/GNUmakefile	Thu Jun 28 09:35:06 2012 +0000
+++ b/GNUmakefile	Thu Jun 28 10:27:07 2012 +0000
@@ -109,7 +109,7 @@
 		xslt/ga.xslt						\
 		xslt/content.xslt
 
-LANGS =		en ja he ru tr
+LANGS =		en ru cn he ja tr
 
 all:		news arx 404 $(LANGS)
 
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/GNUmakefile	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,52 @@
+DOC_LANG =	cn
+
+DOCS =									\
+		introduction						\
+		howto							\
+		faq							\
+		windows							\
+
+DOCS_XML =	$(foreach name, $(DOCS), xml/$(DOC_LANG)/docs/$(name).xml)
+DOCS_HTML =	$(foreach name, $(DOCS), $(OUT)/$(DOC_LANG)/docs/$(name).html)
+
+INTRO =									\
+		http/request_processing					\
+		http/server_names					\
+		http/configuring_https_servers				\
+
+INTRO_XML =	$(foreach name, $(INTRO), xml/$(DOC_LANG)/docs/$(name).xml)
+INTRO_HTML =	$(foreach name, $(INTRO), $(OUT)/$(DOC_LANG)/docs/$(name).html)
+
+HOWTO =									\
+		debugging_log						\
+		http/converting_rewrite_rules				\
+
+HOWTO_XML =	$(foreach name, $(HOWTO), xml/$(DOC_LANG)/docs/$(name).xml)
+HOWTO_HTML =	$(foreach name, $(HOWTO), $(OUT)/$(DOC_LANG)/docs/$(name).html)
+
+FAQ =									\
+		welcome_nginx_facebook					\
+		sys_errlist						\
+
+FAQ_XML =	$(foreach name, $(FAQ), xml/$(DOC_LANG)/docs/$(name).xml)
+FAQ_HTML =	$(foreach name, $(FAQ), $(OUT)/$(DOC_LANG)/docs/$(name).html)
+
+$(DOC_LANG):								\
+		$(OUT)/$(DOC_LANG)/index.html				\
+		$(OUT)/$(DOC_LANG)/docs/index.html			\
+		$(DOCS_HTML)						\
+		$(INTRO_HTML)						\
+		$(HOWTO_HTML)						\
+		$(FAQ_HTML)						\
+
+$(OUT)/$(DOC_LANG)/docs/index.html:					\
+		$(DOCS_XML)						\
+
+$(OUT)/$(DOC_LANG)/docs/introduction.html:				\
+		$(INTRO_XML)						\
+
+$(OUT)/$(DOC_LANG)/docs/howto.html:					\
+		$(HOWTO_XML)						\
+
+$(OUT)/$(DOC_LANG)/docs/faq.html:					\
+		$(FAQ_XML)						\
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/debugging_log.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,62 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="调试日志"
+         link="/cn/docs/debugging_log.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+要开启调试日志，首先需要在配置nginx时打开调试功能，然后编译：
+
+<programlisting>
+./configure --with-debug ...
+</programlisting>
+
+然后在配置文件中设置<literal>error_log</literal>的级别为<literal>debug</literal>：
+
+<programlisting>
+error_log  /path/to/log  debug;
+</programlisting>
+
+nginx的windows二进制版本总是将调试日志开启的，因此只需要设置<literal>debug</literal>的日志级别即可。
+</para>
+
+<para>
+注意，在其他级别定义日志，如在<i>server</i>层次，会关闭该主机的日志：
+<programlisting>
+error_log  /path/to/log  debug;
+
+http {
+    server {
+        error_log  /path/to/log;
+        ...
+</programlisting>
+应该注释掉这条server日志，或者也增加<literal>debug</literal>标志：
+<programlisting>
+error_log  /path/to/log  debug;
+
+http {
+    server {
+        error_log  /path/to/log  debug;
+        ...
+</programlisting>
+</para>
+
+<para>
+另外，也可以只针对某些地址开启调试日志：
+
+<programlisting>
+error_log  /path/to/log;
+
+events {
+    debug_connection   192.168.1.1;
+    debug_connection   192.168.10.0/24;
+}
+</programlisting>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/faq.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,26 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx faq"
+         link="/cn/docs/faq.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="welcome_nginx_facebook.xml"/>
+</listitem>
+
+<listitem>
+<link doc="sys_errlist.xml"/>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/howto.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,26 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx howto"
+         link="/cn/docs/howto.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="debugging_log.xml"/>
+</listitem>
+
+<listitem>
+<link doc="http/converting_rewrite_rules.xml"/>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/http/configuring_https_servers.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,386 @@
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="配置HTTPS服务器"
+         link="/cn/docs/http/configuring_https_servers.html"
+         lang="cn"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+<section>
+
+<para>
+配置HTTPS主机，必须在server配置块中打开SSL协议，还需要指定服务器端证书和密钥文件的位置：
+
+<programlisting>
+server {
+    listen               443;
+    server_name          www.nginx.com;
+    ssl                  on;
+    ssl_certificate      www.nginx.com.crt;
+    ssl_certificate_key  www.nginx.com.key;
+    ssl_protocols        SSLv3 TLSv1;
+    ssl_ciphers          HIGH:!aNULL:!MD5;
+    ...
+}
+</programlisting>
+
+服务器证书是公开的，会被传送到所有连接到服务器的客户端。而私钥不是公开的，需要存放在访问受限的文件中，当然，nginx主进程必须有读取密钥的权限。还有一种情况，私钥和证书存放在同一个文件中：
+
+
+<programlisting>
+    ssl_certificate      www.nginx.com.cert;
+    ssl_certificate_key  www.nginx.com.cert;
+</programlisting>
+
+
+这种情况下，证书文件同样得设置访问限制。当然，虽然证书和密钥存放在同一个文件，只有证书会发送给客户端，密钥不会发送。
+</para>
+
+<para>
+
+<literal>ssl_protocols</literal>和<literal>ssl_ciphers</literal>指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始，nginx默认使用<literal>ssl_protocols SSLv3 TLSv1</literal>和<literal>ssl_ciphers HIGH:!aNULL:!MD5</literal>，所以只有在之前的版本，明确地配置它们才是有意义的。
+</para>
+
+<para>
+CBC模式的加密算法容易受到一些攻击，尤其是BEAST攻击（参见<link url="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389">CVE-2011-3389</link>）。可以通过下面配置调整为优先使用RC4-SHA加密算法：
+
+<programlisting>
+    ssl_ciphers RC4:HIGH:!aNULL:!MD5;
+    ssl_prefer_server_ciphers on;
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="optimization" name="HTTPS服务器优化">
+
+<para>
+SSL操作需要消耗CPU资源，所以在多处理器的系统，需要启动多个工作进程，而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手，有两种方法可以将每个客户端的握手操作数量降到最低：第一种是保持客户端长连接，在一个SSL连接发送多个请求，第二种是在并发的连接或者后续的连接中重用SSL会话参数，这样可以避免SSL握手的操作。会话缓存用于保存SSL会话，这些缓存在工作进程间共享，可以使用<literal>ssl_session_cache</literal>指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟，可以使用<literal>ssl_session_timeout</literal>来修改。下面是一个针对4核系统的配置优化的例子，使用10M的共享会话缓存：
+
+<programlisting>
+<b>worker_processes  4</b>;
+
+http {
+    <b>ssl_session_cache    shared:SSL:10m</b>;
+    <b>ssl_session_timeout  10m</b>;
+
+    server {
+        listen               443;
+        server_name          www.nginx.com;
+        <b>keepalive_timeout    70</b>;
+
+        ssl                  on;
+        ssl_certificate      www.nginx.com.crt;
+        ssl_certificate_key  www.nginx.com.key;
+        ssl_protocols        SSLv3 TLSv1;
+        ssl_ciphers          HIGH:!aNULL:!MD5;
+        ...
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="chains" name="SSL证书链">
+
+<para>
+有些浏览器不接受那些众所周知的证书认证机构签署的证书，而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构，这些中间机构被众所周知的证书认证机构授权代为签发证书，但是它们自己却不被广泛认知，所以有些客户端不予识别。针对这种情况，证书认证机构提供一个证书链的包裹，用来声明众所周知的认证机构和自己的关系，需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里，服务器证书需要出现在认证方证书链的前面：
+
+<programlisting>
+$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt
+</programlisting>
+
+这个文件需要使用<literal>ssl_certificate</literal>指令来引用：
+
+<programlisting>
+server {
+    listen               443;
+    server_name          www.nginx.com;
+    ssl                  on;
+    ssl_certificate      www.nginx.com.chained.crt;
+    ssl_certificate_key  www.nginx.com.key;
+    ...
+}
+</programlisting>
+
+如果服务器证书和认证方证书链合并时顺序弄错了，nginx就不能正常启动，而且会显示下面的错误信息：
+
+<programlisting>
+SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
+   (SSL: error:0B080074:x509 certificate routines:
+    X509_check_private_key:key values mismatch)
+</programlisting>
+
+因为nginx首先需要用私钥去解密服务器证书，而遇到的却是认证方的证书。
+</para>
+
+<para>
+浏览器通常会将那些被受信的认证机构认证的中间认证机构保存下来，那么这些浏览器以后在遇到使用这些中间认证机构但不包含证书链的情况时，因为已经保存了这些中间认证机构的信息，所以不会报错。可以使用<command>openssl</command>命令行工具来确认服务器发送了完整的证书链：
+<programlisting>
+$ openssl s_client -connect www.godaddy.com:443
+...
+Certificate chain
+ 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
+     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
+     /OU=MIS Department/<b>CN=www.GoDaddy.com</b>
+     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
+   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+ 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
+     /OU=http://certificates.godaddy.com/repository
+     /CN=Go Daddy Secure Certification Authority
+     /serialNumber=07969287
+   i:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+ 2 s:/C=US/O=The Go Daddy Group, Inc.
+     /OU=Go Daddy Class 2 Certification Authority
+   i:/L=ValiCert Validation Network/O=<b>ValiCert, Inc.</b>
+     /OU=ValiCert Class 2 Policy Validation Authority
+     /CN=http://www.valicert.com//emailAddress=info@valicert.com
+...
+</programlisting>
+
+在这个例子中，www.GoDaddy.com的服务器证书（#0）的受签者（“s”）是被签发机构（“i”）签名的，而这个签发机构又是证书（#1）的受签者，接着证书（#1）的签发机构又是证书（#2）的受签者，最后证书（#2）是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中，被浏览器自动识别。
+</para>
+
+<para>
+如果没有加入认证方证书链，那只能看到服务器证书（#0）。
+</para>
+
+</section>
+
+
+<section id="single_http_https_server" name="统一的HTTP/HTTPS主机">
+
+<para>
+从开始就将HTTP主机和HTTPS主机分开配置是很好一个很好的实践。虽然它们的功能现在看来是一样的，但是这个情况将来可能会有很大变化，那么合在一起的配置就有问题了。如果HTTP和HTTPS主机配置相同，而又不考虑将来重写配置的话，可以用一个主机配置统一处理HTTP和HTTPS请求。方法是删除<literal>ssl on</literal>的配置项，并在*:443端口添加参数<literal>ssl</literal>：
+<programlisting>
+server {
+    listen               80;
+    listen               443  ssl;
+    server_name          www.nginx.com;
+    ssl_certificate      www.nginx.com.crt;
+    ssl_certificate_key  www.nginx.com.key;
+    ...
+}
+</programlisting>
+
+<note>
+在0.8.21版本以前，只有添加了<literal>default</literal>参数的监听端口才能添加<literal>ssl</literal>参数：
+<programlisting>
+listen  443  default  ssl;
+</programlisting>
+</note>
+</para>
+
+</section>
+
+
+<section id="name_based_https_servers" name="基于名字的HTTPS主机">
+
+<para>
+在同一个IP上配置多个HTTPS主机，会出现问题：
+
+<programlisting>
+server {
+    listen           443;
+    server_name      www.nginx.com;
+    ssl              on;
+    ssl_certificate  www.nginx.com.crt;
+    ...
+}
+
+server {
+    listen           443;
+    server_name      www.nginx.org;
+    ssl              on;
+    ssl_certificate  www.nginx.org.crt;
+    ...
+}
+</programlisting>
+
+使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机的证书，比方说就是<url>www.nginx.com</url>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后，才能发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。
+</para>
+
+<para>
+最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址：
+
+<programlisting>
+server {
+    listen           192.168.1.1:443;
+    server_name      www.nginx.com;
+    ssl              on;
+    ssl_certificate  www.nginx.com.crt;
+    ...
+}
+
+server {
+    listen           192.168.1.2:443;
+    server_name      www.nginx.org;
+    ssl              on;
+    ssl_certificate  www.nginx.org.crt;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="certificate_with_several_names"
+        name="带有多个主机名的SSL证书">
+
+<para>
+也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如<url>www.nginx.com</url>和<url>www.nginx.org</url>。这种方法的限制是“SubjectAltName”字段的长度。
+</para>
+
+<para>
+另一种方式是使用主机名中含有通配符的证书，比如<url>*.nginx.org</url>。这个证书匹配<url>www.nginx.org</url>，但是不匹配<url>nginx.org</url>和<url>www.sub.nginx.org</url>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如<url>nginx.org</url>和<url>*.nginx.org</url>。
+</para>
+
+<para>
+最好将带有多个名字的证书和它的密钥文件配置在http配置块中，这样可以只保存一份内容拷贝，所有主机的配置都从中继承：
+
+<programlisting>
+ssl_certificate      common.crt;
+ssl_certificate_key  common.key;
+
+server {
+    listen           443;
+    server_name      www.nginx.com;
+    ssl              on;
+    ...
+}
+
+server {
+    listen           443;
+    server_name      www.nginx.org;
+    ssl              on;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="sni" name="主机名指示">
+
+<para>
+在一个IP上运行多个HTTPS主机的更通用的方案是<link url="http://en.wikipedia.org/wiki/Server_Name_Indication">TLSv1.1 主机名指示扩展</link>（SNI，RFC3546），它允许浏览器和服务器进行SSL握手时，将请求的主机名传递服务器，因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息：
+</para>
+
+<list type="bullet">
+
+<listitem>
+Opera 8.0；
+</listitem>
+
+<listitem>
+MSIE 7.0（仅在Windows Vista操作系统及后续操作系统）；
+</listitem>
+
+<listitem>
+Firefox 2.0和使用Mozilla平台1.8.1版本的其他浏览器；
+</listitem>
+
+<listitem>
+Safari 3.2.1（Windows版需要最低Vista操作系统）；
+</listitem>
+
+<listitem>
+Chrome（Windows版需要最低Vista操作系统）。
+</listitem>
+
+</list>
+
+<para>
+为了在nginx中使用SNI，那么无论是在编译nginx时使用的OpenSSL类库，还是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL通过<nobr>&ldquo;--enable-tlsext&rdquo;</nobr>配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示如下信息：
+
+<programlisting>
+$ nginx -V
+...
+TLS SNI support enabled
+...
+</programlisting>
+
+但是，当开启SNI支持的nginx被动态链接到不支持SNI的OpenSSL库上时，nginx会显示如下警告：
+
+<programlisting>
+nginx was built with SNI support, however, now it is linked
+dynamically to an OpenSSL library which has no tlsext support,
+therefore SNI is not available
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="compatibility" name="兼容性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+从0.8.21和0.7.62版本开始，使用“-V”选项运行nginx时，将显示SNI支持状态信息。
+</listitem>
+
+<listitem>
+从0.7.14版本开始，<literal>listen</literal>指令支持<literal>ssl</literal>参数。
+</listitem>
+
+<listitem>
+从0.5.32版本开始，支持SNI。
+</listitem>
+
+<listitem>
+从0.5.6版本开始，支持SSL会话缓存，并可在工作进程间共享。
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+0.7.65、0.8.19及以后版本，默认SSL协议是SSLv3和TLSv1。
+</listitem>
+
+<listitem>
+0.7.64、0.8.18及以前版本，默认SSL协议是SSLv2、SSLv3和TLSv1。
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+1.0.5及以后版本，默认SSL密码算法是<literal>HIGH:!aNULL:!MD5</literal>。
+</listitem>
+
+<listitem>
+0.7.65、0.8.20及以后版本，默认SSL密码算法是<literal>HIGH:!ADH:!MD5</literal>。
+</listitem>
+
+<listitem>
+0.8.19版本，默认SSL密码算法是<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM</literal>。
+</listitem>
+
+<listitem>
+0.7.64、0.8.18及以前版本，默认SSL密码算法是<literal>ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP</literal>。
+</listitem>
+
+</list>
+</para>
+
+
+</section>
+
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/http/converting_rewrite_rules.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,144 @@
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="转换rewrite规则"
+         link="/cn/docs/http/converting_rewrite_rules.html"
+         lang="cn">
+
+
+<section name="重定向到主站">
+
+<para>
+共享站点的管理员，习惯于<i>只</i>在Apache下使用.htaccess文件配置<i>所有</i>信息，通常会将下面规则
+
+<programlisting>
+RewriteCond  %{HTTP_HOST}  nginx.org
+RewriteRule  (.*)          http://www.nginx.org$1
+</programlisting>
+
+翻译成这样：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  www.nginx.org  nginx.org;
+    if ($http_host = nginx.org) {
+        rewrite  (.*)  http://www.nginx.org$1;
+    }
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+这种做法是错的，复杂而且低效。正确的方式是为<url>nginx.org</url>定义一个单独的服务器：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org;
+    return       301 http://www.nginx.org$request_uri;
+}
+
+server {
+    listen       80;
+    server_name  www.nginx.org;
+    ...
+}
+</programlisting>
+
+<note>
+在0.9.1版本（含）以前，可以这样实现重定向：
+<programlisting>
+    rewrite      ^ http://www.nginx.org$request_uri?;
+</programlisting>
+</note>
+
+</para>
+
+</section>
+
+
+<section>
+
+<para>
+再举一个例子，处理一个和刚才相反的逻辑：既不是来自<url>nginx.com</url>，又不是来自<url>www.nginx.com</url>：
+
+<programlisting>
+RewriteCond  %{HTTP_HOST}  !nginx.com
+RewriteCond  %{HTTP_HOST}  !www.nginx.com
+RewriteRule  (.*)          http://www.nginx.com$1
+</programlisting>
+
+应该按下面这样分开定义<url>nginx.com</url>、<url>www.nginx.com</url>和其他站点：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.com www.nginx.com;
+    ...
+}
+
+server {
+    listen       80 default_server;
+    server_name  _;
+    return       301 http://nginx.com$request_uri;
+}
+</programlisting>
+
+<note>
+在0.9.1版本（含）以前，可以这样实现重定向：
+<programlisting>
+    rewrite      ^ http://nginx.com$request_uri?;
+</programlisting>
+</note>
+
+</para>
+
+</section>
+
+
+<section id="converting_mongrel_rules"
+        name="转化混合规则">
+
+<para>
+典型的混合规则如下：
+
+<programlisting>
+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/index.html [QSA,L]
+
+RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
+</programlisting>
+
+转换成nginx配置应该是这样：
+
+<programlisting>
+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;
+}
+</programlisting>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/http/request_processing.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,216 @@
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="Nginx如何处理一个请求"
+         link="/cn/docs/http/request_processing.html"
+         lang="cn"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+
+<section name="基于名字的虚拟主机">
+
+<para>
+Nginx首先选定由哪一个<i>虚拟主机</i>来处理请求。让我们从一个简单的配置（其中全部3个虚拟主机都在端口*：80上监听）开始：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org  www.nginx.org;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  nginx.net  www.nginx.net;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  nginx.com  www.nginx.com;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+在这个配置中，nginx仅仅检查请求的Host头以决定该请求应由哪个虚拟主机来处理。如果Host头没有匹配到任意一个主机名，或者请求中根本没有包含这个头，那nginx会将这个请求分发到默认的虚拟主机。在以上配置中，第一个被列出的虚拟主机即nginx的默认虚拟主机——这是nginx的标准默认行为。如果不想第一个虚拟主机成为默认主机，可以显式地在"<literal>listen</literal>"指令中设置"<literal>default_server</literal>"参数：
+
+<programlisting>
+server {
+    listen       80  <b>default_server</b>;
+    server_name  nginx.net  www.nginx.net;
+    ...
+}
+</programlisting>
+
+<note>
+"<literal>default_server</literal>"参数从0.8.21版开始使用。在之前的版本中，需要使用"<literal>default</literal>"参数代替。
+</note>
+
+请注意"<literal>default_server</literal>"是监听端口的属性，而不是主机名的属性。后面会对此有更多介绍。
+</para>
+
+</section>
+
+
+<section id="how_to_prevent_undefined_server_names"
+        name="如何防止处理未定义主机名的请求">
+
+<para>
+如果不想处理未定义<header>Host</header>头的请求，可以定义如下主机，以丢弃这些请求：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  "";
+    return       444;
+}
+</programlisting>
+
+在这里，我们设置主机名为空字符串以匹配未定义<header>Host</header>头的请求，而且返回了一个nginx特有的，非http标准的返回码444，它可以用来关闭连接。从0.8.48版本开始，这已成为主机名的默认设置，所以<literal>server_name ""</literal>可以省略。而之前的版本使用机器的<i>hostname</i>作为默认主机名。
+</para>
+
+</section>
+
+
+<section id="mixed_name_ip_based_servers"
+        name="基于域名和IP混合的虚拟主机">
+
+<para>
+下面让我们来看一个复杂点的配置，在这个配置里，有几个虚拟主机在不同的地址上监听：
+
+<programlisting>
+server {
+    listen       192.168.1.1:80;
+    server_name  nginx.org  www.nginx.org;
+    ...
+}
+
+server {
+    listen       192.168.1.1:80;
+    server_name  nginx.net  www.nginx.net;
+    ...
+}
+
+server {
+    listen       192.168.1.2:80;
+    server_name  nginx.com  www.nginx.com;
+    ...
+}
+</programlisting>
+
+这个配置中，nginx根据"<literal>server</literal>"配置块中的"<literal>listen</literal>"指令首先测试请求的IP地址和端口是否匹配某个定义的值。如果匹配成功，则继续测试请求的Host头是否匹配这个块中的"<literal>server_name</literal>"的值。如果主机名匹配失败，这个请求将被交给默认的虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问<url>www.nginx.com</url>的请求将被监听192.168.1.1:80端口的默认服务器处理，本例中就是第一个服务器，因为这个端口上没有定义域名为<url>www.nginx.com</url>的服务器。
+</para>
+
+<para>
+之前已经提到默认服务器是监听端口的属性，所以不同的监听端口可以设置不同的默认服务器：
+
+<programlisting>
+server {
+    listen        192.168.1.1:80;
+    server_name   nginx.org  www.nginx.org;
+    ...
+}
+
+server {
+    listen        192.168.1.1:80  default_server;
+    server_name   nginx.net  www.nginx.net;
+    ...
+}
+
+server {
+    listen        192.168.1.2:80  default_server;
+    server_name   nginx.com  www.nginx.com;
+    ...
+}
+</programlisting>
+</para>
+
+</section>
+
+
+<section id="simple_php_site_configuration"
+        name="一个简单PHP站点配置">
+
+<para>
+现在让我们来看一下，在一个典型的，简单的PHP站点中，nginx怎样为一个请求选择<i>location</i>来处理：
+
+<programlisting>
+server {
+    listen        80;
+    server_name   nginx.org  www.nginx.org;
+    root          /data/www;
+
+    location / {
+        index     index.html  index.php;
+    }
+
+    location ~* \.(gif|jpg|png)$ {
+        expires   30d;
+    }
+
+    location ~ \.php$ {
+        fastcgi_pass   localhost:9000;
+        fastcgi_param  SCRIPT_FILENAME
+                       $document_root$fastcgi_script_name;
+        include        fastcgi_params;
+    }
+}
+</programlisting>
+</para>
+
+<para>
+第一步，nginx使用字符串匹配找出最准确的location，这一步nginx会忽略location在配置文件出现的顺序。上面的配置中，只有唯一一个非正则匹配的location，也就是"<literal>/</literal>"，它可以匹配任意的请求，一般作为最后一个选择。第二步，nginx会继续匹配正则表达式的location，匹配到第一个正则表达式后停止搜索。匹配到的location将被使用。正则表达式的匹配，按照配置中的顺序进行，出现在前的优先匹配。如果没有匹配到正则表达式，则使用第一步匹配的结果。
+</para>
+
+<para>
+请注意所有location匹配测试只使用请求的URI部分，而不使用参数部分。这是因为参数在请求串中顺序是任意的，比如：
+
+<programlisting>
+/index.php?user=john&amp;page=1
+/index.php?page=1&amp;user=john
+</programlisting>
+
+除此以外，任何人在请求串中都可以随意添加字符串：
+
+<programlisting>
+/index.php?page=1&amp;something+else&amp;user=john
+</programlisting>
+</para>
+
+<para>
+现在让我们来看一下使用上面的配置进来的请求是怎样被处理的：
+
+<list type="bullet">
+
+<listitem>
+<para>
+请求"<literal>/logo.gif</literal>"首先匹配上location "<literal>/</literal>"，然后匹配上正则表达式"<literal>\.(gif|jpg|png)$</literal>"。因此，它将被后匹配上的location处理。根据"<literal>root /data/www</literal>"指令，nginx将请求映射到文件"<literal>/data/www/logo.gif</literal>"，并发送这个文件到客户端。
+</para>
+</listitem>
+
+<listitem>
+<para>
+请求"<literal>/index.php</literal>"首先也匹配上location "<literal>/</literal>"，然后匹配上正则表达式"<literal>\.(php)$</literal>"。 因此，它将被后匹配上的location处理，会被发送到一个监听在localhost:9000的FastCGI服务器。"<literal>fastcgi_param</literal>"指令将FastCGI的参数SCRIPT_FILENAME的值设置为"<literal>/data/www/index.php</literal>"，接着FastCGI服务器将执行这个文件。变量$document_root等于"<literal>root</literal>"指令设置的值，变量$fastcgi_script_name的值等于请求的uri，"<literal>/index.php</literal>"。
+</para>
+</listitem>
+
+<listitem>
+<para>
+请求"<literal>/about.html</literal>"仅能匹配上location "<literal>/</literal>"，因此，它将使用此location进行处理。根据"<literal>root /data/www</literal>"指令，nginx将请求映射到文件"<literal>/data/www/about.html</literal>"，并发送这个文件到客户端。
+</para>
+</listitem>
+
+<listitem>
+<para>
+请求"<literal>/</literal>"的处理更为复杂。它仅能匹配上location "<literal>/</literal>"，因此，它将使用此location进行处理。然后，"<literal>index</literal>"指令使用它的参数和"<literal>root /data/www</literal>"指令所组成的文件路径来检测对应的文件是否存在。如果文件"<literal>/data/www/index.php</literal>"存在，"<literal>index</literal>"指令将执行一次内部重定向到"<literal>/index.php</literal>"，接着nginx将重新寻找匹配"<literal>/index.php</literal>"的location，就好像这次请求是从客户端发过来一样。正如我们之前看到的那样，这个重定向的请求最终交给FastCGI服务器来处理。
+</para>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/http/server_names.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,348 @@
+<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd">
+
+<article name="虚拟主机名"
+         link="/cn/docs/http/server_names.html"
+         lang="cn"
+         author="Igor Sysoev"
+         editor="Brian Mercer">
+
+
+<section>
+
+<para>
+
+虚拟主机名使用<literal>server_name</literal>指令定义，并用于决定某个请求应由哪台虚拟主机处理。具体请参考《<link doc="request_processing.xml">nginx如何处理一个请求</link>》。虚拟主机名可以使用确切的名字，通配符，或者是正则表达式来定义：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org  www.nginx.org;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  *.nginx.org;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  mail.*;
+    ...
+}
+
+server {
+    listen       80;
+    server_name  ~^(?&lt;user&gt;.+)\.nginx\.net$;
+    ...
+}
+</programlisting>
+
+nginx将以下面顺序检测名字：
+
+<list type="enum">
+
+<listitem>
+确切的名字；
+</listitem>
+
+<listitem>
+以星号起始的通配符名字：<url>*.nginx.org</url>；
+</listitem>
+
+<listitem>
+以星号结束的通配符名字：<url>mail.*</url>；
+</listitem>
+
+<listitem>
+正则表达式名字，按在配置文件中出现的顺序遍历。
+</listitem>
+
+</list>
+一旦匹配成功，停止搜索。
+</para>
+
+</section>
+
+
+<section id="wildcard_names"
+        name="通配符名字">
+
+<para>
+通配符名字只可以在名字的起始处或结尾处包含一个星号，并且星号与其他字符之间用点分隔。所以，<literal>www.*.nginx.org</literal>和<literal>w*.nginx.org</literal>都是非法的。不过，上面的两个名字可以使用正则表达式描述：<literal>~^www\..+\.nginx\.org$</literal>和<literal>~^w.*\.nginx\.org$</literal>。星号可以匹配名字的多个节（各节都是以点号分隔的），比如<literal>*.nginx.org</literal>不仅匹配<url>www.nginx.org</url>，也匹配<url>www.sub.nginx.org</url>。
+</para>
+
+<para>
+有一种形如<literal>.nginx.org</literal>的特殊通配符，它可以既匹配确切的名字<literal>nginx.org</literal>，又可以匹配一般的通配符名字<literal>*.nginx.org</literal>。
+</para>
+
+</section>
+
+
+<section id="regex_names"
+        name="正则表达式名字">
+
+<para>
+nginx使用兼容PCRE的正则表达式。为了使用正则表达式，虚拟主机名必须以波浪线“~”起始：
+
+<programlisting>
+server_name  ~^www\d+\.nginx\.net$;
+</programlisting>
+
+否则该名字会被认为是确切的名字，如果表达式含星号，则会被认为是通配符名字（很可能是一个非法的通配符名字）。不要忘记设置&ldquo;^&rdquo;和&ldquo;$&rdquo;锚点，语法上不是必须的，但是逻辑上是需要的。同时需要注意的是，域名中的点&ldquo;.&rdquo;需要用反斜线&ldquo;\&rdquo;转义。正则表达式中含有&ldquo;{&rdquo;和&ldquo;}&rdquo;，那么正则表达式需要被引用，如：
+
+<programlisting>
+server_name  "~^(?&lt;name&gt;\w\d<b>{</b>1,3<b>}</b>+)\.nginx\.net$";
+</programlisting>
+
+否则nginx就不能启动，错误提示是：
+
+<programlisting>
+directive "server_name" is not terminated by ";" in ...
+</programlisting>
+
+命名的正则表达式捕获组在后面可以作为变量使用：
+
+<programlisting>
+server {
+    server_name   ~^(www\.)?(<b>?&lt;domain&gt;</b>.+)$;
+
+    location / {
+        root   /sites/<b>$domain</b>;
+    }
+}
+</programlisting>
+
+PCRE使用下面语法支持命名捕获组：
+
+<table note="yes">
+
+<tr>
+<td><literal>?&lt;<value>name</value>&gt;</literal></td>
+<td>从PCRE-7.0开始支持，兼容Perl 5.10语法</td>
+</tr>
+
+<tr>
+<td><literal>?'<value>name</value>'</literal></td>
+<td>从PCRE-7.0开始支持，兼容Perl 5.10语法</td>
+</tr>
+
+<tr>
+<td><literal>?P&lt;<value>name</value>&gt;</literal></td>
+<td>从PCRE-4.0开始支持，兼容Python语法</td>
+</tr>
+
+</table>
+
+如果nginx不能启动，并显示错误信息：
+
+<programlisting>
+pcre_compile() failed: unrecognized character after (?&lt; in ...
+</programlisting>
+
+说明PCRE版本太旧，应该尝试使用<literal>?P&lt;name&gt;</literal>。捕获组也可以以数字方式引用：
+
+<programlisting>
+server {
+    server_name   ~^(www\.)?(.+)$;
+
+    location / {
+        root   /sites/<b>$2</b>;
+    }
+}
+</programlisting>
+
+不过，这种用法只限于简单的情况（比如上面的例子），因为数字引用很容易被覆盖。
+</para>
+
+
+</section>
+
+
+<section id="miscellaneous_names"
+        name="其他类型的名字">
+
+<para>
+如果需要用一个非默认的虚拟主机处理请求头中不含&ldquo;Host&rdquo;字段的请求，需要指定一个空名字：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org  www.nginx.org  "";
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+如果server块中没有定义<literal>server_name</literal>，nginx使用空名字作为虚拟主机名。
+<note>
+同样的情况下，nginx 0.8.48版本以下（含）使用<i>本地主机名</i>作为虚拟主机名。
+</note>
+</para>
+
+<para>
+如果使用IP地址而不是主机名来请求服务器，那么请求头的&ldquo;HOST&rdquo;字段包含的将是IP地址。可以将IP地址作为虚拟主机名来处理这种请求：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org
+                 www.nginx.org
+                 ""
+                 <b>192.168.1.1</b>
+                 ;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+在匹配所有的服务器的例子中，可以见到一个奇怪的名字&ldquo;_&rdquo;：
+
+<programlisting>
+server {
+    listen       80  default_server;
+    server_name  _;
+    return       444;
+}
+</programlisting>
+
+这没什么特别的，它只不过是成千上万的与真实的名字毫不相干的非法域名中的一个而已。当然，也可以使用&ldquo;--&rdquo;、&ldquo;!@#&rdquo;等等。
+</para>
+
+<para>
+nginx直到0.6.25版本还支持一个特殊的名字&ldquo;*&rdquo;，这个名字一直被错误地理解成是一个匹配所有的名字。但它从来没有像匹配所有的名字，或者通配符那样工作过，而是用来支持一种功能，此功能现在已经改由<literal>server_name_in_redirect</literal>指令提供支持了。所以，现在这个特殊的名字&ldquo;*&rdquo;就过时了，应该使用<literal>server_name_in_redirect</literal>指令。需要注意的是，使用<literal>server_name</literal>指令无法描述匹配所有的名字或者默认服务器，需要使用<literal>listen</literal>指令的一个属性来完成这项工作。具体请参考《<link doc="request_processing.xml">nginx如何处理一个请求</link>》。可以定义两个服务器都监听*:80和*:8080端口，然后指定一个作为端口*:8080的默认服务器，另一个作为端口*:80的默认服务器：
+
+<programlisting>
+server {
+    listen       80;
+    listen       8080  default_server;
+    server_name  nginx.net;
+    ...
+}
+
+server {
+    listen       80  default_server;
+    listen       8080;
+    server_name  nginx.org;
+    ...
+}
+</programlisting>
+</para>
+
+
+</section>
+
+
+<section id="optimization"
+        name="优化">
+
+<para>
+确切名字和通配符名字存储在哈希表中。哈希表和监听端口关联，每个端口都最多关联到三张表：确切名字的哈希表，以星号起始的通配符名字的哈希表和以星号结束的通配符名字的哈希表。哈希表的尺寸在配置阶段进行了优化，可以以最小的CPU缓存命中失败来找到名字。nginx首先搜索确切名字的哈希表，如果没有找到，搜索以星号起始的通配符名字的哈希表，如果还是没有找到，继续搜索以星号结束的通配符名字的哈希表。因为名字是按照域名的节来搜索的，所以搜索通配符名字的哈希表比搜索确切名字的哈希表慢。注意<literal>.nginx.org</literal>存储在通配符名字的哈希表中，而不在确切名字的哈希表中。正则表达式是一个一个串行的测试，所以是最慢的，而且不可扩展。
+</para>
+
+<para>
+鉴于以上原因，请尽可能使用确切的名字。举个例子，如果使用<url>nginx.org</url>和<url>www.nginx.org</url>来访问服务器是最频繁的，那么将它们明确的定义出来就更为有效：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  nginx.org  www.nginx.org  *.nginx.org;
+    ...
+}
+</programlisting>
+
+下面这种方法相比更简单，但是效率也更低：
+
+<programlisting>
+server {
+    listen       80;
+    server_name  .nginx.org;
+    ...
+}
+</programlisting>
+</para>
+
+<para>
+如果定义了大量名字，或者定义了非常长的名字，那就需要在<i>http</i>配置块中调整<literal>server_names_hash_max_size</literal>和<literal>server_names_hash_bucket_size</literal>的值。<literal>server_names_hash_bucket_size</literal>的默认值可能是32，或者是64，或者是其他值，取决于CPU的缓存行的长度。如果这个值是32，那么定义&ldquo;too.long.server.name.nginx.org&rdquo;作为虚拟主机名就会失败，显示下面错误信息： 
+<programlisting>
+could not build the server_names_hash,
+you should increase server_names_hash_bucket_size: 32
+</programlisting>
+
+出现了这种情况，那就需要将设置值扩大一倍：
+
+<programlisting>
+http {
+    server_names_hash_bucket_size  64;
+    ...
+</programlisting>
+
+如果定义了大量名字，得到了另外一个错误：
+
+<programlisting>
+could not build the server_names_hash,
+you should increase either server_names_hash_max_size: 512
+or server_names_hash_bucket_size: 32
+</programlisting>
+
+那么应该先尝试设置<literal>server_names_hash_max_size</literal>的值差不多等于名字列表的名字总量。如果还不能解决问题，或者服务器启动非常缓慢，再尝试提高<literal>server_names_hash_bucket_size</literal>的值。
+</para>
+
+<para>
+如果只为一个监听端口配置了唯一的主机，那么nginx就完全不会测试虚拟主机名了（也不会建立那些名字哈希表）。不过，有一个例外，如果<literal>server_name</literal>是一个含有捕获组的正则表达式，这时nginx就不得不执行这个表达式以得到捕获组。
+</para>
+
+</section>
+
+
+<section id="compatibility"
+        name="兼容性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+从0.8.48版本开始，默认的虚拟主机名是空名字&ldquo;&rdquo;。
+</listitem>
+
+<listitem>
+从0.8.25版本开始，支持虚拟主机名中使用命名的正则表达式捕获组。
+</listitem>
+
+<listitem>
+从0.7.40版本开始，支持虚拟主机名中使用正则表达式的捕获组。
+</listitem>
+
+<listitem>
+从0.7.12版本开始，支持空名字&ldquo;&rdquo;。
+</listitem>
+
+<listitem>
+从0.6.25版本开始，通配符和正则表达式名字可以作为第一个虚拟主机名。
+</listitem>
+
+<listitem>
+从0.6.7版本开始，支持正则表达式的虚拟主机名。
+</listitem>
+
+<listitem>
+从0.6.0版本开始，支持形如<url>nginx.*</url>的通配符名字。
+</listitem>
+
+<listitem>
+从0.3.18版本开始，支持形如<url>.nginx.org</url>的特殊通配符名字。
+</listitem>
+
+<listitem>
+从0.1.13版本开始，支持形如<url>*.nginx.org</url>的通配符名字。
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/index.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,40 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx文档"
+         link="/cn/docs/"
+         lang="cn">
+
+
+<section>
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="introduction.xml"/>
+</listitem>
+
+<listitem>
+<link doc="howto.xml"/>
+</listitem>
+
+<listitem>
+<link doc="faq.xml"/>
+</listitem>
+
+</list>
+</para>
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="windows.xml"/>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/introduction.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,30 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx介绍"
+         link="/cn/docs/introduction.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+<list type="bullet">
+
+<listitem>
+<link doc="http/request_processing.xml"/>
+</listitem>
+
+<listitem>
+<link doc="http/server_names.xml"/>
+</listitem>
+
+<listitem>
+<link doc="http/configuring_https_servers.xml"/>
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/sys_errlist.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,25 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="关于“&lsquo;sys_errlist&rsquo; is deprecated; use &lsquo;strerror&rsquo; or &lsquo;strerror_r&rsquo; instead”的提示"
+         link="/cn/docs/sys_errlist.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+在Linux环境下编译nginx 0.7.66、0.8.35或更高版本时，会出现以下警告：
+
+<programlisting>
+warning: `sys_errlist' is deprecated;
+    use `strerror' or `strerror_r' instead
+warning: `sys_nerr' is deprecated;
+    use `strerror' or `strerror_r' instead
+</programlisting>
+
+这属于正常情况：nginx必须在信号处理函数中使用过时的sys_errlist[]和sys_nerr，因为strerror()和strerror_r()是非异步信号安全的。
+</para>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/welcome_nginx_facebook.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,37 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="我尝试打开Facebook，但得到的是一个“Welcome to nginx!”的页面"
+         link="/cn/docs/welcome_nginx_facebook.html"
+         lang="cn">
+
+<section>
+
+<para>
+<initial>问：</initial>
+我尝试打开Facebook，Yahoo!，Google，或者其他一些知名网站时，但是得到的都是空白页，上面有一条与nginx相关的信息：“Welcome to nginx!”或者是“404 Not Found / nginx”。
+</para>
+
+
+<para>
+我怀疑出了什么问题，而且有可能有恶意的企图要把我引导到流氓页面去（为了黑掉我的电脑，钓鱼等等）。为什么？nginx跟我想连上Facebook（Yahoo!，Google等等）有什么关系？
+</para>
+
+
+<para>
+&nbsp;
+</para>
+
+<para>
+<initial>答：</initial>
+nginx是世界上最流行的三种web服务器之一。它是一个免费的开源软件，完全合法，和任何威胁或者恶意活动毫无关系。“Welcome to nginx!”的网页是一个运行nginx的服务器可能的诊断返回之一。
+</para>
+
+
+<para>
+然而，你认为你的电脑或操作系统设置一定出问题了的假设是正确的——当你尝试访问一些知名网站的时候，得到的不是熟悉的页面反而是“Welcome to nginx!”。如果你的电脑是干净且安全的，就不应该出现这种情况。我们建议你检查并且核实你的操作系统设置（可能需要ISP或者支持人员的帮助），而且在你的电脑上安装并运行杀毒软件是一个好主意。可能有些邪恶的组织正在窃听从你电脑发出的数据流，而且潜在地可能对你和Internet上的其他用户造成巨大危害。
+</para>
+
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/docs/windows.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,121 @@
+<!DOCTYPE article SYSTEM "../../../dtd/article.dtd">
+
+<article name="nginx Windows版使用说明"
+         link="/cn/docs/windows.html"
+         lang="cn">
+
+
+<section>
+
+<para>
+nginx的Windows版本使用原生Win32 API（非Cygwin模拟层）。当前nginx/Windows只使用<i>select</i>作为通知方法，所以不要期待它有很高的性能和扩展性。鉴于这点和一些已知问题，nginx/Windows目前还处于<i>beta</i>阶段。nginx/Windows和Unix版本相比，功能几乎已经齐全，除了XSLT过滤器、图像过滤器、GeoIP模块和嵌入Perl语言支持以外。
+</para>
+
+<para>
+安装nginx/Windows，需要<link doc="../download.xml">下载</link>最新的<development_version />开发版本，因为开发分支上包含了所有已知的问题修复，尤其是针对Windows版本的问题修复。解压缩下载得到的zip文件，进入nginx-<development_version />目录，运行nginx。下面给出一个在C盘根目录下安装的例子：
+
+<programlisting>
+cd c:\
+unzip nginx-<development_version />.zip
+cd nginx-<development_version />
+start nginx
+</programlisting>
+
+可以在命令行运行<command>tasklist</command>命令来查看nginx进程：
+
+<programlisting>
+C:\nginx-<development_version />&gt;tasklist /fi "imagename eq nginx.exe"
+
+Image Name           PID Session Name     Session#    Mem Usage
+=============== ======== ============== ========== ============
+nginx.exe            652 Console                 0      2 780 K
+nginx.exe           1332 Console                 0      3 112 K
+</programlisting>
+
+其中一个是主进程，另一个是工作进程。如果nginx没有启动，请查看<path>logs\error.log</path>文件以寻找失败原因。如果日志文件不存在，那失败原因会记录在Windows事件日志中。如果某次请求没有展示预想的页面，而是展示了错误页面，也请查看<path>logs\error.log</path>文件。
+</para>
+
+<para>
+nginx/Windows使用工作目录作为前缀将配置文件中设置的相对目录补齐。就上面安装的例子而言，工作目录应该是<path>C:\nginx-<development_version />\</path>（工作目录基本上与运行文件所在的目录相同）。配置文件中的目录请使用“/”，而不是“\”做目录分隔：
+
+<programlisting>
+access_log   logs/site.log;
+root         C:/web/html;
+</programlisting>
+</para>
+
+<para>
+nginx/Windows作为标准控制台应用运行，而不是系统服务。可以用下面的命令控制：
+
+<table note="yes">
+
+<tr>
+<td width="20%">nginx -s stop</td>
+<td>快速退出</td>
+</tr>
+
+<tr>
+<td>nginx -s quit</td>
+<td>优雅退出</td>
+</tr>
+
+<tr>
+<td>nginx -s reload</td>
+<td>
+更换配置，启动新的工作进程，优雅的关闭以往的工作进程
+</td>
+</tr>
+
+<tr>
+<td>nginx -s reopen</td>
+<td>重新打开日志文件</td>
+</tr>
+
+</table>
+</para>
+
+</section>
+
+<section id="known_issues"
+        name="已知问题">
+
+<list type="bullet">
+
+<listitem>
+虽然可以启动若干工作进程运行，实际上只有一个进程在处理请求所有请求。
+</listitem>
+
+<listitem>
+一个工作进程只能处理不超过1024个并发连接。
+</listitem>
+
+<listitem>
+缓存和其他需要共享内存支持的模块在Windows Vista及后续版本的操作系统中无法工作，因为在这些操作系统中，地址空间的布局是随机的。
+</listitem>
+
+</list>
+
+</section>
+
+<section id="possible_future_enhancements"
+        name="日后可能加强的功能">
+
+<list type="bullet">
+
+<listitem>
+作为系统服务运行。
+</listitem>
+
+<listitem>
+使用“I/O完成端口”作为事件模型。
+</listitem>
+
+<listitem>
+使用单工作进程多线程的模型。
+</listitem>
+
+</list>
+
+</section>
+
+</article>
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/xml/cn/index.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -0,0 +1,243 @@
+<!DOCTYPE article SYSTEM "../../dtd/article.dtd">
+
+<article name="nginx"
+         link="/cn/"
+         lang="cn">
+
+
+<section>
+
+<para>
+nginx [engine x]是<link url="http://sysoev.ru/en/">Igor Sysoev</link>编写的一个HTTP和反向代理服务器，另外它也可以作为邮件代理服务器。
+它从2004开始已经在众多流量很大的俄罗斯网站上使用，包括<link url="http://www.yandex.ru">Yandex</link>、<link url="http://www.mail.ru">Mail.Ru</link>、<link url="http://www.vkontakte.ru">VKontakte</link>，以及<link url="http://www.rambler.ru">Rambler</link>。据Netcraft统计，在2011年10月份，<link url="http://news.netcraft.com/archives/2011/10/06/september-2011-web-server-survey.htm">世界上最繁忙的网站中有7.84%</link>使用Nginx作为其服务器或者代理服务器。部分成功案例请见：<link url="http://blog.fastmail.fm/2007/01/04/webimappop-frontend-proxies-changed-to-nginx/">FastMail.FM</link>，
+<link url="http://barry.wordpress.com/2008/04/28/load-balancer-update/">Wordpress.com</link>。
+</para>
+
+<para>
+Nginx的源码使用的许可为<link url="http://nginx.org/LICENSE">两条款类BSD协议</link>。
+</para>
+
+</section>
+
+
+<section id="basic_http_features"
+        name="基本的HTTP服务器特性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+处理静态文件，索引文件以及自动索引；打开文件描述符缓存；
+</listitem>
+
+<listitem>
+使用缓存加速反向代理；简单负载均衡以及容错；
+</listitem>
+
+<listitem>
+远程FastCGI服务的缓存加速支持；简单的负载均衡以及容错；
+</listitem>
+
+<listitem>
+模块化的架构。过滤器包括gzip压缩、ranges支持、chunked响应、XSLT，SSI以及图像缩放。在SSI 过滤器中，一个包含多个SSI的页面，如果经由FastCGI或反向代理处理，可被并行处理；
+</listitem>
+
+<listitem>
+支持SSL，TLS SNI。
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="other_http_features"
+        name="其他的HTTP服务器特性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+基于名字和IP的虚拟主机；
+</listitem>
+
+<listitem>
+Keep-alive和pipelined连接支持；
+</listitem>
+
+<listitem>
+灵活的配置；
+</listitem>
+
+<listitem>
+重新加载配置以及在线升级时，不需要中断正在处理的请求；
+</listitem>
+
+<listitem>
+自定义访问日志格式，带缓存的日志写操作以及快速日志轮转；
+</listitem>
+
+<listitem>
+3xx-5xx错误代码重定向；
+</listitem>
+
+<listitem>
+重写（rewrite）模块；
+</listitem>
+
+<listitem>
+基于客户端IP地址和HTTP基本认证机制的访问控制；
+</listitem>
+
+<listitem>
+支持PUT、DELETE、MKCOL、COPY以及MOVE方法；
+</listitem>
+
+<listitem>
+支持FLV流和MP4流；
+</listitem>
+
+<listitem>
+速度限制；
+</listitem>
+
+<listitem>
+来自同一地址的同时连接数或请求数限制；
+</listitem>
+
+<listitem>
+嵌入Perl语言。
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="mail_proxy_server_features"
+        name="邮件代理服务器特性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+使用外部HTTP认证服务器重定向用户到IMAP/POP3后端；
+</listitem>
+
+<listitem>
+使用外部HTTP认证服务器认证用户后重定向连接到内部SMTP后端；
+</listitem>
+
+<listitem>
+支持的认证方式：
+
+<list type="bullet">
+
+<listitem>
+POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+<listitem>
+IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+<listitem>
+SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
+</listitem>
+
+</list>
+</listitem>
+
+<listitem>
+SSL支持；
+</listitem>
+
+<listitem>
+STARTTLS和STLS支持。
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="architecture_and_scalability"
+        name="架构和扩展性">
+
+<para>
+<list type="bullet">
+
+<listitem>
+一个主进程和多个工作进程，工作进程以非特权用户运行；
+</listitem>
+
+<listitem>
+支持的事件机制：kqueue（FreeBSD 4.1+）、epoll（Linux 2.6+）、rt signals（Linux 2.2.19+）、/dev/poll（Solaris 7 11/99+）、event ports（Solaris 10）、select以及poll；
+</listitem>
+
+<listitem>
+众多支持的kqueue特性包括EV_CLEAR、EV_DISABLE（临时禁止事件）、NOTE_LOWAT、EV_EOF，可用数据的数量，错误代码；
+</listitem>
+
+<listitem>
+支持sendfile（FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5）、sendfile64（Linux 2.4.21+）和sendfilev（Solaris 8 7/01+）；
+</listitem>
+
+<listitem>
+文件AIO（FreeBSD 4.3+, Linux 2.6.22+）；
+</listitem>
+
+<listitem>
+Accept-filters（FreeBSD 4.1+）和 TCP_DEFER_ACCEPT（Linux 2.4+）；
+</listitem>
+
+<listitem>
+10000个非活跃的HTTP keep-alive连接仅占用约2.5M内存；
+</listitem>
+
+<listitem>
+尽可能避免数据拷贝操作。
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+<section id="tested_os_and_platforms"
+        name="测试过的操作系统和平台">
+
+<para>
+<list type="bullet">
+
+<listitem>
+FreeBSD 3 &mdash; 8 / i386; FreeBSD 5 &mdash; 9 / amd64;
+</listitem>
+
+<listitem>
+Linux 2.2 &mdash; 2.6 / i386; Linux 2.6 / amd64;
+</listitem>
+
+<listitem>
+Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
+</listitem>
+
+<listitem>
+MacOS X / ppc, i386;
+</listitem>
+
+<listitem>
+Windows XP, Windows Server 2003.
+</listitem>
+
+</list>
+</para>
+
+</section>
+
+
+</article>
--- a/xml/i18n.xml	Thu Jun 28 09:35:06 2012 +0000
+++ b/xml/i18n.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -27,6 +27,20 @@
 <item id="dirindex">Алфавитный указатель директив</item>
 </text>
 
+<text lang="cn">
+<item id="and">和</item>
+<item id="author">作者</item>
+<item id="editor">编辑</item>
+<item id="translator">翻译</item>
+<item id="syntax">语法</item>
+<item id="default">默认值</item>
+<item id="context">上下文</item>
+<item id="context.any">任意</item>
+<item id="directive.version">这个指令出现在版本</item>
+<item id="directive.versions">这个指令出现在版本</item>
+<item id="dirindex">指令目录</item>
+</text>
+
 <text lang="ja">
 <item id="author">作成:</item>
 <item id="translator">翻訳:</item>
--- a/xml/menu.xml	Thu Jun 28 09:35:06 2012 +0000
+++ b/xml/menu.xml	Thu Jun 28 10:27:07 2012 +0000
@@ -2,12 +2,49 @@
 
 <menus>
 
+<menu lang="cn">
+
+<item href="/en/"> english </item>
+<item href="/ru/"> русский </item>
+<item />
+
+<item> 简体中文 </item>
+<item href="/he/"> עברית </item>
+<item href="/ja/"> 日本語 </item>
+<item href="/tr/"> türkçe </item>
+<item />
+
+<item href="/" lang="en"> 新闻 </item>
+<item />
+
+<item href="/cn/"> nginx 介绍 </item>
+<item href="/en/download.html" lang="en"> 下载 </item>
+<item href="/en/security_advisories.html" lang="en"> 安全漏洞 </item>
+<item href="/cn/docs/"> 文档 </item>
+<item href="/cn/docs/introduction.html"> 入门 </item>
+<item href="/cn/docs/howto.html"> How to </item>
+<item href="/cn/docs/faq.html"> FAQ </item>
+<item href="http://trac.nginx.org/nginx" lang="en"> trac </item>
+<item href="http://wiki.nginx.org" lang="en"> wiki </item>
+<item href="/en/links.html" lang="en"> 外部连接 </item>
+<item href="/en/books.html" lang="en"> 书籍 </item>
+<item href="/en/support.html" lang="en"> 支持 </item>
+<item href="/en/donation.html" lang="en"> 捐献 </item>
+<item href="http://www.nginx.com/"> nginx.com </item>
+<item href="https://twitter.com/nginxorg"> @nginxorg </item>
+
+</menu>
+
+
 <menu lang="en">
 
 <item> english </item>
+<item href="/ru/"> русский </item>
+<item />
+
+<item href="/cn/"> 简体中文 </item>
 <item href="/he/"> עברית </item>
 <item href="/ja/"> 日本語 </item>
-<item href="/ru/"> русский </item>
 <item href="/tr/"> türkçe </item>
 <item />
 
@@ -46,9 +83,12 @@
 <menu lang="he">
 
 <item href="/en/"> english </item>
+<item href="/ru/"> русский </item>
+<item />
+
+<item href="/cn/"> 简体中文 </item>
 <item> עברית </item>
 <item href="/ja/"> 日本語 </item>
-<item href="/ru/"> русский </item>
 <item href="/tr/"> türkçe </item>
 <item />
 
@@ -74,9 +114,12 @@
 <menu lang="ja">
 
 <item href="/en/"> english </item>
+<item href="/ru/"> русский </item>
+<item />
+
+<item href="/cn/"> 简体中文 </item>
 <item href="/he/"> עברית </item>
 <item> 日本語 </item>
-<item href="/ru/"> русский </item>
 <item href="/tr/"> türkçe </item>
 <item />
 
@@ -102,9 +145,12 @@
 <menu lang="ru">
 
 <item href="/en/"> english </item>
+<item> русский </item>
+<item />
+
+<item href="/cn/"> 简体中文 </item>
 <item href="/he/"> עברית </item>
 <item href="/ja/"> 日本語 </item>
-<item> русский </item>
 <item href="/tr/"> türkçe </item>
 <item />
 
@@ -134,9 +180,12 @@
 <menu lang="tr">
 
 <item href="/en/"> english </item>
+<item href="/ru/"> русский </item>
+<item />
+
+<item href="/cn/"> 简体中文 </item>
 <item href="/he/"> עברית </item>
 <item href="/ja/"> 日本語 </item>
-<item href="/ru/"> русский </item>
 <item> türkçe </item>
 <item />