# HG changeset patch # User Maxim Dounin # Date 1707930351 -10800 # Node ID 6c78190bc1cbd57d778da08b947cb9b6b9eed0c3 # Parent 9eadb98ec770c77c315a70a93583c1c7c1ee5401 Free nginx: removed obsolete translations. diff --git a/xml/cn/GNUmakefile b/xml/cn/GNUmakefile deleted file mode 100644 --- a/xml/cn/GNUmakefile +++ /dev/null @@ -1,37 +0,0 @@ -DOCS = \ - faq \ - windows \ - syntax \ - dirindex \ - http/request_processing \ - http/server_names \ - http/configuring_https_servers \ - debugging_log \ - http/converting_rewrite_rules \ - -FAQ = \ - welcome_nginx_facebook \ - sys_errlist \ - -REFS = \ - http/ngx_http_access_module \ - http/ngx_http_addition_module \ - http/ngx_http_auth_basic_module \ - http/ngx_http_autoindex_module \ - http/ngx_http_browser_module \ - http/ngx_http_core_module \ - http/ngx_http_empty_gif_module \ - http/ngx_http_flv_module \ - http/ngx_http_geo_module \ - http/ngx_http_geoip_module \ - http/ngx_http_gzip_static_module \ - http/ngx_http_image_filter_module \ - http/ngx_http_index_module \ - http/ngx_http_limit_conn_module \ - http/ngx_http_limit_req_module \ - http/ngx_http_log_module \ - http/ngx_http_map_module \ - http/ngx_http_proxy_module \ - http/ngx_http_referer_module \ - http/ngx_http_rewrite_module \ - http/ngx_http_upstream_module \ diff --git a/xml/cn/docs/debugging_log.xml b/xml/cn/docs/debugging_log.xml deleted file mode 100644 --- a/xml/cn/docs/debugging_log.xml +++ /dev/null @@ -1,68 +0,0 @@ - - - - -
- - -
- - -要开启调试日志，首先需要在配置nginx时打开调试功能，然后编译： - - -./configure --with-debug ... - - -然后在配置文件中设置error_log的级别为debug： - - -error_log /path/to/log debug; - - -nginx的windows二进制版本总是将调试日志开启的，因此只需要设置debug的日志级别即可。 - - - -注意，重新定义错误日志时，如过没有指定debug级别，调试日志会被屏蔽。下面的例子里，在层中重新定义的日志就屏蔽了这个虚拟主机的调试日志： - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log; - ... - -为了避免这个问题，注释这行重新定义日志的配置，或者也给日志指定debug级别： - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log debug; - ... - - - - -另外，也可以只针对选定的客户端地址开启调试日志： - - -error_log /path/to/log; - -events { - debug_connection 192.168.1.1; - debug_connection 192.168.10.0/24; -} - - - -
- -
diff --git a/xml/cn/docs/faq.xml b/xml/cn/docs/faq.xml deleted file mode 100644 --- a/xml/cn/docs/faq.xml +++ /dev/null @@ -1,26 +0,0 @@ - - -
- - -
- - - - - - - - - - - - - - - -
- -
diff --git a/xml/cn/docs/http/configuring_https_servers.xml b/xml/cn/docs/http/configuring_https_servers.xml deleted file mode 100644 --- a/xml/cn/docs/http/configuring_https_servers.xml +++ /dev/null @@ -1,396 +0,0 @@ - - - - -
- -
- - -配置HTTPS主机，必须在server配置块中打开SSL协议，还需要指定服务器端证书和密钥文件的位置： - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; - ssl_ciphers HIGH:!aNULL:!MD5; - ... -} - - -服务器证书是公开的，会被传送到每一个连接到服务器的客户端。而私钥不是公开的，需要存放在访问受限的文件中，当然，nginx主进程必须有读取密钥的权限。私钥和证书可以存放在同一个文件中： - - - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; - - -这种情况下，证书文件同样得设置访问限制。当然，虽然证书和密钥存放在同一个文件，只有证书会发送给客户端，密钥不会发送。 - - - -和指令可以用来强制用户连接只能引入SSL/TLS那些强壮的协议版本和强大的加密算法。从1.0.5版本开始，nginx默认使用“ssl_protocols SSLv3 TLSv1”和“ssl_ciphers HIGH:!aNULL:!MD5”，所以只有在之前的版本，明确地配置它们才是有意义的。从1.1.13和1.0.12版本开始，nginx默认使用“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”。 - - - -CBC模式的加密算法容易受到一些攻击，尤其是BEAST攻击（参见CVE-2011-3389）。可以通过下面配置调整为优先使用RC4-SHA加密算法： - - - ssl_ciphers RC4:HIGH:!aNULL:!MD5; - ssl_prefer_server_ciphers on; - - - -
- - -
- - -SSL操作需要消耗CPU资源，所以在多处理器的系统，需要启动多个工作进程，而且数量需要不少于可用CPU的个数。最消耗CPU资源的SSL操作是SSL握手，有两种方法可以将每个客户端的握手操作数量降到最低：第一种是保持客户端长连接，在一个SSL连接发送多个请求，第二种是在并发的连接或者后续的连接中重用SSL会话参数，这样可以避免SSL握手的操作。会话缓存用于保存SSL会话，这些缓存在工作进程间共享，可以使用指令进行配置。1M缓存可以存放大约4000个会话。默认的缓存超时是5分钟，可以使用加大它。下面是一个针对4核系统的配置优化的例子，使用10M的共享会话缓存： - - -worker_processes 4; - -http { - ssl_session_cache shared:SSL:10m; - ssl_session_timeout 10m; - - server { - listen 443; - server_name www.example.com; - keepalive_timeout 70; - - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; - ssl_ciphers HIGH:!aNULL:!MD5; - ... - - - -
- - -
- - -有些浏览器不接受那些众所周知的证书认证机构签署的证书，而另外一些浏览器却接受它们。这是由于证书签发使用了一些中间认证机构，这些中间机构被众所周知的证书认证机构授权代为签发证书，但是它们自己却不被广泛认知，所以有些客户端不予识别。针对这种情况，证书认证机构提供一个证书链的包裹，用来声明众所周知的认证机构和自己的关系，需要将这个证书链包裹与服务器证书合并成一个文件。在这个文件里，服务器证书需要出现在认证方证书链的前面： - - -$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt - - -这个文件需要使用指令来引用： - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.chained.crt; - ssl_certificate_key www.example.com.key; - ... -} - - -如果服务器证书和认证方证书链合并时顺序弄错了，nginx就不能正常启动，而且会显示下面的错误信息： - - -SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed - (SSL: error:0B080074:x509 certificate routines: - X509_check_private_key:key values mismatch) - - -因为nginx首先需要用私钥去解密服务器证书，而遇到的却是认证方的证书。 - - - -浏览器通常会将那些被受信的认证机构认证的中间认证机构保存下来，那么这些浏览器以后在遇到使用这些中间认证机构但不包含证书链的情况时，因为已经保存了这些中间认证机构的信息，所以不会报错。可以使用openssl命令行工具来确认服务器发送了完整的证书链： - -$ 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/CN=www.GoDaddy.com - /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=ValiCert, Inc. - /OU=ValiCert Class 2 Policy Validation Authority - /CN=http://www.valicert.com//emailAddress=info@valicert.com -... - - -在这个例子中，www.GoDaddy.com的服务器证书（#0）的受签者（“s”）是被签发机构（“i”）签名的，而这个签发机构又是证书（#1）的受签者，接着证书（#1）的签发机构又是证书（#2）的受签者，最后证书（#2）是被众所周知的签发机构ValiCert, Inc签发。ValiCert, Inc的证书内嵌在浏览器中，被浏览器自动识别（这段话神似英国诗《在Jack盖的房子里》里面的内容）。 - - - -如果没有加入认证方证书链，就只会显示服务器证书（#0）。 - - -
- - -
- - -如果HTTP和HTTPS虚拟主机的功能是一致的，可以配置一个虚拟主机，既处理HTTP请求，又处理HTTPS请求。 -配置的方法是删除ssl on的指令，并在*:443端口添加参数ssl： - -server { - listen 80; - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ... -} - - - -在0.8.21版本以前，只有添加了default参数的监听端口才能添加ssl参数： - -listen 443 default ssl; - - - - -
- - -
- - -如果在同一个IP上配置多个HTTPS主机，会出现一个很普遍的问题： - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - -使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机www.example.com的证书。这是由SSL协议本身的行为引起的——先建立SSL连接，再发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。 - - - -最古老的也是最稳定的解决方法就是每个HTTPS主机使用不同的IP地址： - - -server { - listen 192.168.1.1:443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 192.168.1.2:443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - - -
- - -
- - -也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如www.example.com和www.example.org。但是，“SubjectAltName”字段的长度有限制。 - - - -另一种方式是使用主机名中含有通配符的证书，比如*.example.org。这个证书匹配www.example.org，但是不匹配example.org和www.sub.example.org。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如example.org和*.example.org。 - - - -最好将带有多个名字的证书和它的密钥文件配置在http配置块中，这样可以只保存一份内容拷贝，所有主机的配置都从中继承： - - -ssl_certificate common.crt; -ssl_certificate_key common.key; - -server { - listen 443; - server_name www.example.com; - ssl on; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ... -} - - - -
- - -
- - -在一个IP上运行多个HTTPS主机的更通用的方案是TLS主机名指示扩展（SNI，RFC6066），它允许浏览器和服务器进行SSL握手时，将请求的主机名传递给服务器，因此服务器可以知道使用哪一个证书来服务这个连接。但SNI只得到有限的浏览器的支持。下面列举支持SNI的浏览器最低版本和平台信息： - - - - - - -Opera 8.0； - - - -MSIE 7.0（仅在Windows Vista操作系统及后续操作系统）； - - - -Firefox 2.0和使用Mozilla平台1.8.1版本的其他浏览器； - - - -Safari 3.2.1（Windows版需要最低Vista操作系统）； - - - -Chrome（Windows版需要最低Vista操作系统）。 - - - - -通过SNI只能传递域名，但是，当请求中包含可读的IP地址时，某些浏览器将服务器的IP地址作为服务器的名字进行了传送。这是一个错误，大家不应该依赖于这个。 - - - - -为了在nginx中使用SNI，那么无论是在编译nginx时使用的OpenSSL类库，还是在运行nginx时使用的OpenSSL运行库，都必须支持SNI。从0.9.8f版本开始，OpenSSL通过“--enable-tlsext”配置选项加入SNI支持，从0.9.8j版本开始，此选项成为默认选项。当nginx被编译成支持SNI时，在使用“-V”选项运行时会显示如下信息： - - -$ nginx -V -... -TLS SNI support enabled -... - - -但是，当开启SNI支持的nginx被动态链接到不支持SNI的OpenSSL库上时，nginx会显示如下警告： - - -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 - - - -
- - -
- - - - - -从0.8.21和0.7.62版本开始，使用“-V”选项运行nginx时，将显示SNI支持状态信息。 - - - -从0.7.14版本开始，指令支持ssl参数。 - - - -从0.5.32版本开始，支持SNI。 - - - -从0.5.6版本开始，支持SSL会话缓存，并可在工作进程间共享。 - - - - - - - - - -0.7.65、0.8.19及以后版本，默认SSL协议是SSLv3、TLSv1、TLSc1.1和TLSv1.2（如果OpenSSL库支持）。 - - - -0.7.64、0.8.18及以前版本，默认SSL协议是SSLv2、SSLv3和TLSv1。 - - - - - - - - - -1.0.5及以后版本，默认SSL密码算法是HIGH:!aNULL:!MD5。 - - - -0.7.65、0.8.20及以后版本，默认SSL密码算法是HIGH:!ADH:!MD5。 - - - -0.8.19版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM。 - - - -0.7.64、0.8.18及以前版本，默认SSL密码算法是ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP。 - - - - - - -
- - -
diff --git a/xml/cn/docs/http/converting_rewrite_rules.xml b/xml/cn/docs/http/converting_rewrite_rules.xml deleted file mode 100644 --- a/xml/cn/docs/http/converting_rewrite_rules.xml +++ /dev/null @@ -1,150 +0,0 @@ - - - - -
- - -
- - -共享站点的管理员，习惯于只在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?; - - - - - -
- - -
- - -典型的混合规则如下： - - -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] - - -转换成nginx配置应该是这样： - - -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; -} - - - -
- -
diff --git a/xml/cn/docs/http/ngx_http_access_module.xml b/xml/cn/docs/http/ngx_http_access_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_access_module.xml +++ /dev/null @@ -1,99 +0,0 @@ - - - - - - - - -
- - -模块 ngx_http_access_module 允许限制某些IP地址的客户端访问。 - - - -也可以通过 -密码来限制访问。 -使用 - 指令就能同时通过IP地址和密码来限制访问。 - - -
- - -
- - - -location / { - deny 192.168.1.1; - allow 192.168.1.0/24; - allow 10.1.1.0/16; - allow 2001:0db8::/32; - deny all; -} - - - - -规则按照顺序依次检测，直到匹配到第一条规则。 -在这个例子里，IPv4的网络中只有 -10.1.1.0/16 和 192.168.1.0/24允许访问，但 -192.168.1.1除外, -对于IPv6的网络，只有2001:0db8::/32允许访问。 -在规则很多的情况下，使用 -ngx_http_geo_module -模块变量更合适。 - - -
- - -
- - - - address | - CIDR | - all - -http -server -location -limit_except - - -允许指定的网络地址访问。 - - - - - - - - address | - CIDR | - all - -http -server -location -limit_except - - -拒绝指定的网络地址访问。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_addition_module.xml b/xml/cn/docs/http/ngx_http_addition_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_addition_module.xml +++ /dev/null @@ -1,83 +0,0 @@ - - - - - - - - -
- - -ngx_http_addition_module 是一个过滤模块，它可以在回复正文前后加上内容。 -这个模块默认不会编译进去，若要开启需加上编译选项：--with-http_addition_module。 - - -
- - -
- - - -location / { - add_before_body /before_action; - add_after_body /after_action; -} - - - -
- - -
- - -uri - -location - - -在回复正文之前加入一段文字，nginx会发起一个子请求去获取这些文字。 - - - - - - -uri - -location - - -在回复正文之后加入一段文字，nginx会发起一个子请求去获取这些文字。 - - - - - - -mime-type ... -text/html -http -server -location -0.7.9 - - -指定生效的回复MIME类型，默认始终包含“text/html”。 -如果设置类型为“*”，就会匹配任何类型的回复(0.8.29)。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_auth_basic_module.xml b/xml/cn/docs/http/ngx_http_auth_basic_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_auth_basic_module.xml +++ /dev/null @@ -1,92 +0,0 @@ - - - - - - - - -
- - -模块ngx_http_auth_basic_module 允许使用“HTTP基本认证”协议验证用户名和密码来限制对资源的访问。 - - - -也可以通过 -地址来限制访问。 -使用 指令就能同时通过地址和密码来限制访问。 - - -
- - -
- - - -location / { - auth_basic "closed site"; - auth_basic_user_file conf/htpasswd; -} - - - -
- - -
- - -string | off -off -http -server -location -limit_except - - -开启使用“HTTP基本认证”协议的用户名密码验证。 -指定的参数被用作 域。 -参数off可以取消继承自上一个配置等级 -auth_basic 指令的影响。 - - - - - - -file - -http -server -location -limit_except - - -指定保存用户名和密码的文件，格式如下： - -# comment -name1:password1 -name2:password2:comment -name3:password3 - - - - -密码应该使用crypt函数加密。 -可以用Apache发行包中的htpasswd命令来创建此类文件。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_autoindex_module.xml b/xml/cn/docs/http/ngx_http_autoindex_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_autoindex_module.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - - - - - -
- - -ngx_http_autoindex_module 模块可以列出目录中的文件。 -一般当ngx_http_index_module模块找不到默认主页的时候，会把请求转给 ngx_http_autoindex_module模块去处理。 - - -
- - -
- - - -location / { - autoindex on; -} - - - -
- - -
- - -on | off -off -http -server -location - - -开启或者关闭列出目录中文件的功能。 - - - - - - -on | off -on -http -server -location - - -设置目录中列出的文件是显示精确大小，还是对KB，MB，GB进行四舍五入。 - - - - - - -on | off -off -http -server -location - - -设置目录中列出文件的时间是本地时间还是UTC时间。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_browser_module.xml b/xml/cn/docs/http/ngx_http_browser_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_browser_module.xml +++ /dev/null @@ -1,160 +0,0 @@ - - - - - - - - -
- - -模块ngx_http_browser_module创建变量，它们的值取决于 -请求头中
User-Agent
的值： - - -$modern_browser - -如果浏览器被为识别为新式浏览器，该值等于指令设置的值； - - -$ancient_browser - -如果浏览器被识别为旧式浏览器，该值等于指令设置的值； - - -$msie - -如果浏览器被识别为任何版本的MSIE，该值等于“1”。 - - - - - -
- - -
- - -选择一个默认页: - -modern_browser_value "modern."; - -modern_browser msie 5.5; -modern_browser gecko 1.0.0; -modern_browser opera 9.0; -modern_browser safari 413; -modern_browser konqueror 3.0; - -index index.${modern_browser}html index.html; - - - - -旧式浏览器的重定向： - -modern_browser msie 5.0; -modern_browser gecko 0.9.1; -modern_browser opera 8.0; -modern_browser safari 413; -modern_browser konqueror 3.0; - -modern_browser unlisted; - -ancient_browser Links Lynx netscape4; - -if ($ancient_browser) { - rewrite ^ /ancient.html; -} - - - -
- - -
- - -string ... - -http -server -location - - -如果任一指定的子串在请求头的
User-Agent
域中被发现，浏览器将被认定为旧式浏览器。 -特殊字符串“netscape4” 相当于正则表达式“^Mozilla/[1-4]”。 - - - - - - -string -1 -http -server -location - - -设定变量$ancient_browser的值。 - - - - - - -browser version -unlisted - -http -server -location - - -指定一个版本，此版本及后续版本的浏览器都被认定为新式浏览器。 -浏览器可以是下列之一： msie, -gecko (基于Mozilla), -opera，safari, -或者 konqueror。 - - - -版本可被指定为以下形式：X, X.X, X.X.X, 或 X.X.X.X。 -每一形式的最大值分别是4000, 4000.99, 4000.99.99, 和 4000.99.99.99。 - - - -浏览器既没有在modern_browser中列出，又没有在中 -列出时，如果配置了特殊值unlisted，那么浏览器将被认定为新式浏览器，否则 -认定为旧式浏览器。 -如果请求头中没有
User-Agent
域，浏览器以没有列出对待。 - - - - - - -string -1 -http -server -location - - -设定变量$modern_browser的值。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_core_module.xml b/xml/cn/docs/http/ngx_http_core_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_core_module.xml +++ /dev/null @@ -1,2543 +0,0 @@ - - - - - - - - -
- - - - on | - off | - sendfile -off -http -server -location -0.8.11 - - -在FreeBSD和Linux操作系统上启用或者禁用异步文件I/O(AIO)。 - - - -从FreeBSD 4.3版本开始，可以使用AIO。AIO既可以静态链接到内核中： - -options VFS_AIO - -又可以作为内核模块动态加载： - -kldload aio - - - - -在FreeBSD第5版和第6版，静态启动AIO，或者在系统启动时动态加载AIO，都会触发网络子系统使用一把大锁，进而对整个系统的性能造成负面影响。 -这个限制在2009年发布的FreeBSD 6.4稳定版和FreeBSD 7中被消除。 -虽然如此，仍有方法在5.3及以上版本的FreeBSD中开启AIO而不触发网络子系统的大锁，那就是在内核启动以后加载AIO模块。 -使用这种时，/var/log/messages中会出现下面信息， - -WARNING: Network stack Giant-free, but aio requires Giant. -Consider adding 'options NET_WITH_GIANT' or setting debug.mpsafenet=0 - -但可以安全的忽略它。 - -使用AIO大锁的是FreeBSD套接字上的aio_read和aio_write异步操作。但是nginx仅仅在磁盘I/O使用AIO，所以不会出现问题。 - - - - -为了让AIO工作，需要关闭： - -location /video/ { - sendfile off; - aio on; - output_buffers 1 64k; -} - - - - -不过，从FreeBSD 5.2.1版和nginx 0.8.12版开始，AIO也可以为sendfile预读数据： - -location /video/ { - sendfile on; - tcp_nopush on; - aio sendfile; -} - - -这个配置使nginx在调用sendfile时带SF_NODISKIO参数， -那么sendfile在数据没有读入内存的时候，就不会阻塞在磁盘I/O上，而是直接返回报告；接着nginx就读这个一字节报告，然后初始化异步数据。 -FreeBSD内核接着会读取文件的开始128K字节到内存，而后续的读取只会以16K的单位来进行。 -这个性质可以使用指令来调节。 - - - -从Linux内核2.6.22版开始，也可以使用AIO。但必须同时开启，否则读取将是阻塞的： - -location /video/ { - aio on; - directio 512; - output_buffers 1 128k; -} - - - - -在Linux上，只在读取的块的边界对齐512字节（在XFS上是4K字节）时才有用。在读取文件尾部时， -如果没有对齐，AIO读取还是阻塞的。同样的情况(如果数据的开始或者结尾未对齐时，读取也是阻塞的) -也发生在含有
byte range
头的请求中，或者发生在不是从头开始的FLV请求中。 -没有必要手动关闭，因为如果使用了，它就会自动关闭。 - - - - - - -path - -location - - -定义指定路径的替换路径。比如下面配置 - -location /i/ { - alias /data/w3/images/; -} - -“/i/top.gif”将由/data/w3/images/top.gif文件来响应。 - - - -path的值可以包含变量，但不能使用$document_root和$realpath_root这两个变量。 - - - -如果在定义了正则表达式的路径中使用了alias，那么正则表达式中应该含有匹配组， -并且alias应该引用这些匹配组(0.7.40版)来组成一个完整的文件路径，比如： - -location ~ ^/users/(.+\.(?:gif|jpe?g|png))$ { - alias /data/w3/images/$1; -} - - - - -如果路径对应指令path值的最后一部分： - -location /images/ { - alias /data/w3/images/; -} - -最好换用指令： - -location /images/ { - root /data/w3; -} - - - - - - - -on | off -on -http -server -location - - -允许关闭HTTP/1.1中的分块传输编码。在客户端软件不支持分块传输编码的时候，这条指令才有用。 - - - - - - - -size -8k|16k -http -server -location - - -设置读取客户端请求正文的缓冲容量。如果请求正文大于缓冲容量，整个正文或者正文的一部分将写入临时文件。 -缓冲大小默认等于两块内存页的大小，在x86平台、其他32位平台和x86-64平台，这个值是8K。在其他64位平台，这个值一般是16K。 - - - - - - - - on | - clean | - off -off -http -server -location - - -决定nginx是否将客户端请求正文整个写入文件。这条指令在调试时，或者使用$request_body_file变量时， -或者使用ngx_http_perl_module模块的 -$r->request_body_file方法时都可以使用。 - - - -当指令值设置为on时，请求处理结束后不会删除临时文件。 - - - -当指令值设置为clean时，请求处理结束后会删除临时文件。 - - - - - - -on | off -off -http -server -location - - -决定nginx将整个客户端请求正文保存在一块缓冲中。 -这条指令推荐在使用$request_body变量时使用，可以节省引入的拷贝操作。 - - - - - - - - path - [level1 - [level2 - [level3]]] -client_body_temp -http -server -location - - -定义存储客户端请求正文的临时文件的目录。 -支持在指定目录下多达3层的子目录结构。比如下面配置 - -client_body_temp_path /spool/nginx/client_temp 1 2; - -存储临时文件的路径是 - -/spool/nginx/client_temp/7/45/00000123457 - - - - - - - -time -60s -http -server -location - - -定义读取客户端请求正文的超时。超时是指相邻两次读操作之间的最大时间间隔，而不是整个请求正文完成传输的最大时间。 -如果客户端在这段时间内没有传输任何数据，nginx将返回错误到客户端。 - - - - - - -size -1k -http -server - - -设置读取客户端请求头部的缓冲容量。 -对于大多数请求，1K的缓冲足矣。 -但如果请求中含有的cookie很长，或者请求来自WAP的客户端，可能请求头不能放在1K的缓冲中。 -如果从请求行，或者某个请求头开始不能完整的放在这块空间中，那么nginx将按照 -指令的配置分配更多更大的缓冲来存放。 -directive. - - - - - - -time -60s -http -server - - -定义读取客户端请求头部的超时。如果客户端在这段时间内没有传送完整的头部到nginx， -nginx将返回错误到客户端。 - - - - - - -size -1m -http -server -location - - -设置允许客户端请求正文的最大长度。请求的长度由
Content-Length
请求头指定。 -如果请求的长度超过设定值，nginx将返回错误到客户端。 -请注意浏览器不能正确显示这个错误。 -将size设置成0可以使nginx不检查客户端请求正文的长度。 - - - - - - -size -256 -http -server - - -允许微调为每个连接分配的内存。这条指令对nginx的性能影响非常小，一般不应该使用。 - - - - - - -mime-type -text/plain -http -server -location - - -定义响应的默认MIME类型。设置文件扩展名和响应的MIME类型的映射表则使用指令。 - - - - - - -size | off -off -http -server -location -0.7.7 - - -当读入长度大于等于指定size的文件时，开启DirectIO功能。 -具体的做法是， -在FreeBSD或Linux系统开启使用O_DIRECT标志， -在Mac OS X系统开启使用F_NOCACHE标志， -在Solaris系统开启使用directio功能。 -这条指令自动关闭(0.7.15版)。 -它在处理大文件时 - -directio 4m; - -或者在Linux系统使用时比较有用。 - - - - - - -size -512 -http -server -location -0.8.11 - - -为设置文件偏移量对齐。大多数情况下，按512字节对齐足矣， -但在Linux系统下使用XFS，需要将值扩大到4K。 - - - - - - -off - - on | - if_not_owner - [from=part] -off -http -server -location -1.1.15 - - -决定nginx打开文件时如何处理符号链接： - - -off - -默认行为，允许路径中出现符号链接，不做检查。 - - -on - -如果文件路径中任何组成部分中含有符号链接，拒绝访问该文件。 - - -if_not_owner - -如果文件路径中任何组成部分中含有符号链接，且符号链接和链接目标的所有者不同，拒绝访问该文件。 - - -from=part - -当nginx进行符号链接检查时(参数on和参数if_not_owner)，路径中所有部分默认都会被检查。 -而使用from=part参数可以避免对路径开始部分进行符号链接检查，而只检查后面的部分路径。 -如果某路径不是以指定值开始，整个路径将被检查，就如同没有指定这个参数一样。 -如果某路径与指定值完全匹配，将不做检查。 -这个参数的值可以包含变量。 - - - - - - -比如： - -disable_symlinks on from=$document_root; - - - - -这条指令只在有openat和fstatat接口的系统上可用。 -当然，现在的FreeBSD、Linux和Solaris都支持这些接口。 - - - -参数on和if_not_owner会带来处理开销。 - -只在那些不支持打开目录查找文件的系统中，使用这些参数需要工作进程有这些被检查目录的读权限。 - - - - - -ngx_http_autoindex_module模块， -ngx_http_random_index_module模块 -和ngx_http_dav_module模块目前忽略这条指令。 - - - - - - - - - code ... - [=[response]] - uri - -http -server -location -if in location - - -为指令错误定义显示的URI。当前配置级别没有error_page指令时，将从上层配置继承。 -uri可以包含变量。 - - - -比如： - -error_page 404 /404.html; -error_page 500 502 503 504 /50x.html; - - - - -而且，可以使用“=response语法改变响应状态码。比如： - -error_page 404 =200 /empty.gif; - - - - -如果URI将被发送到一个被代理的服务器处理，或者发送到一个FastCGI服务器处理， -这些后端服务器又返回了不同的响应状态码（比如200、302、401或404），那么这些返回的状态码也可以由本指令处理： - -error_page 404 = /404.php; - - - - -当然，也可以使用本指令对错误处理进行重定向： - -error_page 403 http://example.com/forbidden.html; -error_page 404 =301 http://example.com/notfound.html; - -对于例子中的第一行，nginx将向客户端发送302响应状态码。这种用法能使用的状态码只有301、302、303和307。 - - - -如果内部跳转时无需改变URI，可以将错误处理转到一个命名路径： - -location / { - error_page 404 = @fallback; -} - -location @fallback { - proxy_pass http://backend; -} - - - - - -如果处理uri产生了错误，那么nginx将最后一次出错的HTTP响应状态码返回给客户端。 - - - - - - - -on | off -on -http -server -location -1.3.3 - - -开启或关闭为静态文件自动计算
ETag
响应头。 - - - - - - - - -main - -为HTTP服务器提供配置上下文。 - - - - - - - off | - exact | - before -exact -http -server -location -0.7.24 - - -指定响应的修改时间和
If-Modified-Since
请求头的比较方法： - - - -off - -忽略
If-Modified-Since
请求头(0.7.34)； - - -exact - -精确匹配； - - -before - -响应的修改时间小于等于
If-Modified-Since
请求头指定的时间。 - - - - - - - - - -on | off -on -http -server - - -控制是否忽略非法的请求头字段名。 -合法的名字是由英文字母、数字和连字符组成，当然也可以包含下划线(由指令控制)。 - - - -本指令可以在默认虚拟主机的配置层级中定义一次，那么这个值在监听在相同地址和端口的所有虚拟主机上都生效。 - - - - - - - - -location - - -指定一个路径是否只能用于内部访问。如果是外部访问，客户端将收到错误。 -下列请求是内部请求： - - - - -由指令、指令、 -指令 -和指令引起的重定向请求； - - - -由后端服务器返回的
X-Accel-Redirect
响应头引起的重定向请求； - - - -由ngx_http_ssi_module模块 -和ngx_http_addition_module模块 -的“include virtual”指令产生的子请求； - - - -用指令对请求进行修改。 - - - - - - -举例： - -error_page 404 /404.html; - -location /404.html { - internal; -} - - -nginx限制每个请求只能最多进行10次内部重定向，以防配置错误引起请求处理出现问题。 -如果内部重定向次数已达到10次，nginx将返回错误。 -同时，错误日志中将有“rewrite or internal redirection cycle”的信息。 - - - - - - - -none | browser ... -msie6 -http -server -location - - -针对行为异常的浏览器关闭长连接功能。 -browser参数指定那些浏览器会受到影响。 -值为msie6表示在遇到POST请求时，关闭与老版MSIE浏览器建立长连接。 -值为safari表示在遇到Mac OS X和类Mac OS X操作系统下的Safari浏览器和类Safari浏览器时，不与浏览器建立长连接。 -值为none表示为所有浏览器开启长连接功能。 - -在nginx 1.1.18版本及以前，safari将匹配所有操作系统上的Safari和类Safari浏览器，并默认不与这些浏览器建立长连接。 - - - - - - - -number -100 -http -server -location -0.8.0 - - -设置通过一个长连接可以处理的最大请求数。 -请求数超过此值，长连接将关闭。 - - - - - - - - timeout - [header_timeout] -75s -http -server -location - - -第一个参数设置客户端的长连接在服务器端保持的最长时间（在此时间客户端未发起新请求，则长连接关闭）。 -第二个参数为可选项，设置
Keep-Alive: timeout=time
响应头的值。 -可以为这两个参数设置不同的值。 - - - -
Keep-Alive: timeout=time
响应头可以被Mozilla和Konqueror浏览器识别和处理。 -MSIE浏览器在大约60秒后会关闭长连接。 - - - - - - -number size -4 8k -http -server - - -设置读取客户端请求超大请求的缓冲最大number(数量)和每块缓冲的size(容量)。 -HTTP请求行的长度不能超过一块缓冲的容量，否则nginx返回错误到客户端。 -每个请求头的长度也不能超过一块缓冲的容量，否则nginx返回错误到客户端。 -缓冲仅在必需是才分配，默认每块的容量是8K字节。 -即使nginx处理完请求后与客户端保持入长连接，nginx也会释放这些缓冲。 - - - - - - -method ... - -location - - -允许按请求的HTTP方法限制对某路径的请求。method用于指定不由这些限制条件进行过滤的HTTP方法，可选值有 -GET、 -HEAD、 -POST、 -PUT、 -DELETE、 -MKCOL、 -COPY、 -MOVE、 -OPTIONS、 -PROPFIND、 -PROPPATCH、 -LOCK、 -UNLOCK -或者 -PATCH。 -指定method为GET方法的同时，nginx会自动添加HEAD方法。 -那么其他HTTP方法的请求就会由指令引导的配置块中的ngx_http_access_module -模块和ngx_http_auth_basic_module模块的指令来限制访问。如： - -limit_except GET { - allow 192.168.1.0/32; - deny all; -} - -请留意上面的例子将对除GET和HEAD方法以外的所有HTTP方法的请求进行访问限制。 - - - - - - -rate -0 -http -server -location -if in location - - -限制向客户端传送响应的速率限制。参数rate的单位是字节/秒，设置为0将关闭限速。 - -nginx按连接限速，所以如果某个客户端同时开启了两个连接，那么客户端的整体速率是这条指令设置值的2倍。 - - - -也可以利用$limit_rate变量设置流量限制。如果想在特定条件下限制响应传输速率，可以使用这个功能： - -server { - - if ($slow) { - set $limit_rate 4k; - } - - ... -} - - - - -此外，也可以通过
X-Accel-Limit-Rate
响应头来完成速率限制。 -这种机制可以用指令和 -指令关闭。 - - - - - - -size -0 -http -server -location -if in location -0.8.0 - - -设置不限速传输的响应大小。当传输量大于此值时，超出部分将限速传送。 - - - -比如: - -location /flv/ { - flv; - limit_rate_after 500k; - limit_rate 50k; -} - - - - - - - - - off | - on | - always -on -http -server -location -1.1.0 -1.0.6 - - -控制nginx如何关闭客户端连接。 - - - -默认值“on”指示nginx在完成关闭连接前等待和 -处理客户端发来的额外数据。但只有在预测客户端可能发送更多数据的情况才会做此处理。 - - - -“always”指示nginx无条件等待和处理客户端的额外数据。 - - - -“off”指示nginx立即关闭连接，而绝不等待客户端传送额外数据。 -这样做破坏了协议，所以正常条件下不应使用。 - - - - - - -time -30s -http -server -location - - -生效时，这条指令定义nginx处理(读取但忽略)客户端额外数据的最长时间。 -超过这段时间后，nginx将关闭连接，不论是否还有更多数据待处理。 - - - - - - -time -5s -http -server -location - - -生效时，这条指令定义nginx等待客户端更多数据到来的最长时间。 -如果在这段时间内，nginx没有接收到数据，nginx将关闭连接。否则，nginx将接收数据，忽略它，然后再等待更多数据。 -这个“等待——接收——忽略”的循环一直重复，但总时间不会超过指令定义的时间。 - - - - - - - - address[:port] - [default_server] - [setfib=number] - [backlog=number] - [rcvbuf=size] - [sndbuf=size] - [accept_filter=filter] - [deferred] - [bind] - [ipv6only=on|off] - [ssl] - [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]] - - port - [default_server] - [setfib=number] - [backlog=number] - [rcvbuf=size] - [sndbuf=size] - [accept_filter=filter] - [deferred] - [bind] - [ipv6only=on|off] - [ssl] - [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]] - - unix:path - [default_server] - [backlog=number] - [rcvbuf=size] - [sndbuf=size] - [accept_filter=filter] - [deferred] - [bind] - [ssl] - [so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]] -*:80 | *:8000 -server - - -设置nginx监听地址，nginx从这里接受请求。对于IP协议，这个地址就是address和port；对于UNIX域套接字协议，这个地址就是path。 -一条listen指令只能指定一个address或者port。 -address也可以是主机名。 -比如： - -listen 127.0.0.1:8000; -listen 127.0.0.1; -listen 8000; -listen *:8000; -listen localhost:8000; - -IPv6地址(0.7.36版)用方括号来表示： - -listen [::]:8000; -listen [fe80::1]; - -UNIX域套接字(0.8.21版)则使用“unix:”前缀： - -listen unix:/var/run/nginx.sock; - - - - -如果只定义了address，nginx将使用80端口。 - - - -在没有定义listen指令的情况下，如果以超级用户权限运行nginx，它将监听*:80，否则他将监听*:8000。 - - - -如果listen指令携带default_server参数，当前虚拟主机将成为指定address:port的默认虚拟主机。 -如果任何listen指令都没有携带default_server参数，那么第一个监听address:port的虚拟主机将被作为这个地址的默认虚拟主机。 - -0.8.21版以前，这个参数的名称是default。 - - - - -可以为listen指令定义若干额外的参数，这些参数用于套接字相关的系统调用。 -这些参数可以在任何listen指令中指定，但是对于每个address:port，只能定义一次。 - -0.8.21版以前，只有为listen指令定义了default参数，才能定义这些额外的参数。 - - - - -setfib=number - - -这个参数(0.8.44)为监听套接字设置关联路由表FIB(SO_SETFIB选项)。 -当前这个参数仅工作在FreeBSD上。 - - - -backlog=number - - -为系统调用listen设置backlog参数，用以限制未接受(Accept)连接的队列的最大长度。 -FreeBSD和Mac OS X下，backlog的默认值是-1，在其他系统中，默认值是511。 - - - - -rcvbuf=size - - -为监听套接字设置接收缓冲区大小(SO_RCVBUF参数)。 - - - -sndbuf=size - - -为监听套接字设置发送缓冲区大小(SO_SNDBUF参数)。 - - - -accept_filter=filter - - -为监听套接字设置接受过滤器的名称(SO_ACCEPTFILTER选项)。 -对每个到来的连接，接受过滤器先进行过滤，然后才将它们呈现给accept。 -本特性仅工作在FreeBSD系统和NetBSD 5.0+系统下。 -可接受的值是 -dataready -和 -httpready。 - - - -deferred - - -指示在Linux系统使用延迟的accept(TCP_DEFER_ACCEPT选项)。 - - - -bind - - -指示nginx为设置的address:port单独调用一次bind。 -这是因为当有多条listen指令监听不同地址下的相同端口， -而其中一条listen指令监听了这个端口的所有地址(*:port)时， -nginx只会为*:port调用一次bind绑定套接字。 -需要留意的是，这种情况下，nginx会调用getsockname系统调用来确定接受请求的套接字地址。 -如果为某个address:port定义了参数backlog、rcvbuf、 -sndbuf、accept_filter、deferred或者so_keepalive， -nginx总会为这个地址单独调用一次bind绑定套接字。 - - - -ipv6only=on|off - - -这个参数(0.7.42)(通过IPV6_V6ONLY选项)决定监听在通配地址[::]上的IPv6套接字是只支持IPv6连接，还是同时支持IPv6和IPv4连接。 -这个参数默认打开，并且只能在nginx启动时设置。 - -在1.3.4版以前，如果省略此参数，那么操作系统的套接字设置将生效。 - - - - -ssl - - -本参数(0.7.14)与套接字相关的系统调用无关，但是它可以指定从这个端口接受的连接应该以SSL模式工作。 -本参数在某服务器同时处理HTTP和HTTPS请求时，可以使配置更为紧凑。 - -listen 80; -listen 443 ssl; - - - - -so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt] - - -这个参数(1.1.11)为监听套接字配置“TCP keepalive”行为。 -如果省略此参数，操作系统默认的设置将对此端口生效。 -如果参数值设置为“on”，监听套接字的SO_KEEPALIVE属性将被开启。 -如果参数值设置为“off”，监听套接字的SO_KEEPALIVE属性将被关闭。 -有些操作系统支持为每个连接调整TCP长连接的参数。调整参数可以使用套接字选项TCP_KEEPIDLE，TCP_KEEPINTVL和TCP_KEEPCNT。 -在这些操作系统上(当前就是Linux 2.4+，嬀NetBSD 5+FreeBSD 9.0-STABLE)，可以使用keepidle，keepintvl和keepcnt参数来配置。 -省略一到两个参数的话，对应套接字属性的系统默认设置将生效。 -比如， -so_keepalive=30m::10将 -设置空闲超时(TCP_KEEPIDLE)为30分钟， -设置探测次数(TCP_KEEPCNT)为10次， -保留探测时间间隔(TCP_KEEPINTVL)为系统默认值。 - - - - - - -举例： - -listen 127.0.0.1 default_server accept_filter=dataready backlog=1024; - - - - - - - -[ - = | - ~ | - ~* | - ^~ - ] uri -@name - -server -location - - -为某个请求URI（路径）建立配置。 - - - -路径匹配在URI规范化以后进行。所谓规范化，就是先将URI中形如“%XX”的编码字符进行解码， -再解析URI中的相对路径“.”和“..”部分， -另外还可能会压缩相邻的两个或多个斜线成为一个斜线。 - - - -可以使用前缀字符串或者正则表达式定义路径。使用正则表达式需要在路径开始添加“~*”前缀 -(不区分大小写)，或者“~”前缀(区分大小写)。为了根据请求URI查找路径，nginx先检查前缀字符串定义的路径 -(前缀路径)，在这些路径中找到能最精确匹配请求URI的路径。然后nginx按在配置文件中的出现顺序检查正则表达式路径， -匹配上某个路径后即停止匹配并使用该路径的配置，否则使用最大前缀匹配的路径的配置。 - - - -路径可以嵌套，但有例外，后面将提到。 - - - -在不区分大小写的操作系统（诸如Mac OS X和Cygwin）上，前缀匹配忽略大小写(0.7.7)。但是，比较仅限于单字节的编码区域(one-byte locale)。 - - - -正则表达式中可以包含匹配组(0.7.40)，结果可以被后面的其他指令使用。 - - - -如果最大前缀匹配的路径以“^~”开始，那么nginx不再检查正则表达式。 - - - -而且，使用“=”前缀可以定义URI和路径的精确匹配。如果发现匹配，则终止路径查找。 -比如，如果请求“/”出现频繁，定义“location = /”可以提高这些请求的处理速度， -因为查找过程在第一次比较以后即结束。这样的路径明显不可能包含嵌套路径。 - - - - -在0.7.1到0.8.41的所有nginx中，如果请求匹配的前缀字符串路径并没有“=”或“^~”前缀， -路径查找过程仍然会停止，而不进行正则表达式匹配。 - - - - -让我们用一个例子解释上面的说法： - -location = / { - [ configuration A ] -} - -location / { - [ configuration B ] -} - -location /documents/ { - [ configuration C ] -} - -location ^~ /images/ { - [ configuration D ] -} - -location ~* \.(gif|jpg|jpeg)$ { - [ configuration E ] -} - -请求“/”匹配配置A， -请求“/index.html”匹配配置B， -请求“/documents/document.html”匹配配置C， -请求“/images/1.gif”匹配配置D， -请求“/documents/1.jpg”匹配配置E。 - - - -前缀“@”定义了命名路径。这种路径不在一般的请求处理中使用， -而是用在请求重定向中。这些路径不能嵌套，也不能包含嵌套路径。 - - - - - - - - -on | off -on -http -server -location - - -开启或者关闭在中记录文件不存在的错误。 - - - - - - -on | off -off -http -server -location - - -开启或者关闭在中记录子请求的访问日志。 - - - - - - -number - -http -server -location -1.1.2 - - -如果请求中含有字节范围的请求头，这条指令可以限制此范围允许的最大值。如果请求头的值超过此限制，将按请求未携带此请求头的情况处理。 -默认nginx对此不做限制。设置为0将使nginx完全不支持HTTP字节范围特性。 - - - - - - -on | off -on -http -server - - -开启或者关闭将请求URI中相邻两个或更多斜线合并成一个的功能。 - - - -注意压缩URI对于前缀匹配和正则匹配的正确性是很重要的。没有开启这个功能时，请求“//scripts/one.php”将不能匹配 - -location /scripts/ { - ... -} - -而被按静态文件的流程处理，所以将它变换成“/scripts/one.php”。 - - - -如果URI中包含base64编码的内容，必须将斜线压缩调整成off，因为base64编码本身会使用“/”字符。 -然而。出于安全方面的考虑，最好还是不要关闭压缩。 - - - -这条指令可以指定在默认虚拟主机的配置级别。这样的话，这个配置可以覆盖监听同一地址和端口的所有虚拟主机。 - - - - - - -on | off -on -http -server -location - - -在响应状态码大于等于400时，在响应正文中添加一段注释，使响应正文达到512字节。 -本指令可以为MSIE客户端开启或关闭这个功能。 - - - - - - -on | off -off -http -server -location - - -为MSIE客户端开启或者关闭用页面刷新取代页面重定向的功能。 - - - - - - -off - -max=N -[inactive=time] -off -http -server -location - - -用于配置文件缓存，可缓存： - - - -打开文件的描述符，大小和修改时间； - - - -目录查找结果； - - - -文件查找时的错误结果，诸如“file not found”(文件不存在)、“no read permission”(无读权限)等等。 - -应单独使用指令开启缓存错误结果的功能。 - - - - - - - -指令有下列参数： - - - -max - - -设置缓存中元素的最大数量，当缓存溢出时，使用LRU(最近最少使用)算法删除缓存中的元素； - - - -inactive - - -设置超时，在这段时间内缓存元素如果没有被访问，将从缓存中删除。 -默认超时是60秒； - - - -off - - -关闭缓存。 - - - - - - -举例： - -open_file_cache max=1000 inactive=20s; -open_file_cache_valid 30s; -open_file_cache_min_uses 2; -open_file_cache_errors on; - - - - - - - -on | off -off -http -server -location - - -开启或者关闭缓存文件查找的错误结果。 - - - - - - - - - -number -1 -http -server -location - - -设置在由指令的inactive参数配置的超时时间内， -文件应该被访问的最小number(次数)。如果访问次数大于等于此值，文件描述符会保留在缓存中，否则从缓存中删除。 - - - - - - -time -60s -http -server -location - - -设置检查缓存的元素的时间间隔。 - - - - - - - -on | off -off -http -server - - -这条指令已经被废弃，请使用指令。 - - - - - - - - -on | off -on -http -server -location - - -开启或关闭nginx发起重定向时指定端口。 - - - -重定向中首要主机名的使用由指令控制。 - - - - - - -size -1460 -http -server -location - - -如果可能，到客户端的数据将被推迟发送，直到nginx需要发送的数据至少有size字节。 -设置为0将关闭推迟发送的功能。 - - - - - - -size -0 -http -server -location - - -设置内核参数，控制文件预读的数量。 - - - -在Linux上，因为使用的是posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL)系统调用，所以size无用。 - - - -在FreeBSD上，访问的是fcntl(O_READAHEAD,size)系统调用。 -该系统调用在FreeBSD 9.0-CURRENT才被支持，在FreeBSD 7上则需要打补丁。 - - - - - - -on | off -off -http -server -location - - -允许或禁止指令进行多次重定向。 -允许的话，重定向次数也有限制。 -而禁止此功能时，当访问指令重定向的错误页面出现任何问题时，nginx将直接输出默认错误页面。 - - - - - - -size -4k -http -server - - -允许对每个请求的内存分配进行细调。这条指令对性能影响很小，通常情况下不应使用。 - - - - - - -on | off -off -http -server -location - - -开启或关闭重置超时连接的功能。重置连接是这样执行的：关闭套接字以前，设置SO_LINGER选项的超时值为0， -那么当关闭套接字时，nginx向客户端发送TCP RST，并且释放此套接字占用的所有内存。 -这样可以避免某个已关闭的套接字长时间处于FIN_WAIT1状态，并占用内存缓冲区。 - - - -应该注意的事，超时的长连接仍然是正常关闭。 - - - - - - - -address ... -[valid=time] - -http -server -location - - -配置将后端服务器的名字解析成ip地址的名字服务器，比如： - -resolver 127.0.0.1 [::1]:5353; - -这里地址可以指定域名或者ip地址，可以带端口号(1.3.1，1.2.2)。如果未指定端口，nginx使用53端口。 -以轮询方式发送请求到多台名字服务器。 - -在1.1.7版以前，只允许配置一个名字服务器。而支持使用IPv6地址定义名字服务器则是从1.3.1和1.2.2版本开始。 - -nginx会缓存名字解析的结果。默认情况下，缓存时间是名字解析响应中的TTL字段的值。也允许通过valid参数覆盖它： - -resolver 127.0.0.1 [::1]:5353 valid=30s; - - -在1.1.9版以前，不可能调节缓存时间，nginx总会将响应缓存5分钟。 - - - - - - - -time -30s -http -server -location - - -为名字解析设置超时，比如： - -resolver_timeout 5s; - - - - - - - -path -html -http -server -location -if in location - - -为请求设置根目录。比如，如果配置如下 - -location /i/ { - root /data/w3; -} - -那么nginx将使用文件/data/w3/i/top.gif响应请求“/i/top.gif”。 - - - -path的值中可以包含除$document_root和$realpath_root以外的变量。 - - - -文件路径的构造仅仅是将URI拼在root指令的值后面。如果需要修改URI，应该使用指令。 - - - - - - -all | any -all -http -server -location - - -nginx进行访问限制的有ngx_http_access_module模块和 -ngx_http_auth_basic_module模块。 -本指令设置成all时，表示只有当两个模块的所有限制条件(写入配置的)都授权访问时，允许请求访问； -设置成any时，表示如果当任意模块的任意限制条件授权访问时，允许请求访问。 - - - -举例： - -location / { - satisfy any; - - allow 192.168.1.0/32; - deny all; - - auth_basic "closed site"; - auth_basic_user_file conf/htpasswd; -} - - - - - - - -on | off -off -http -server -location - - -这条指令已被指令的any参数取代。 - - - - - - -size -0 -http -server -location - - -如果设置成非0值，nginx将尝试最小化向客户端发送数据的次数。 -这是通过将方法的NOTE_LOWAT标志， -或者将套接字的SO_SNDLOWAT属性设置成指定的size实现的。 - - - -这条指令在Linux、Solaris和Windows操作系统无效。 - - - - - - -time -60s -http -server -location - - -设置向客户端传输响应的超时。超时仅指两次相邻写操作之间的时间间隔，而非整个响应的传输时间。 -如果客户端在这段时间中没有收到任何数据，连接将关闭。 - - - - - - - -on | off -off -http -server -location -if in location - - -开启或关闭使用sendfile调用。 - - - - - - - -size -0 -http -server -location - - -设置为非0值时，可以限制在一次sendfile调用时传输的数据量。 -如果不进行限制，一个快速的连接可能会霸占整个worker进程的所有资源。 - - - - - - - - -http - - -表示开始设置虚拟主机的配置。 -nginx没有明显分隔IP-based(基于IP地址)和name-based(基于
Host
请求头)这两种类型的虚拟主机， -而是用指令描述虚拟主机接受连接的地址和端口，用指令列出虚拟主机的所有主机名。 -在文档“Nginx如何处理一个请求”中提供了示例配置。 - - - - - - -name ... -"" -server - - -设置虚拟主机名，比如： - -server { - server_name example.com www.example.com; -} - - - - -第一个名字成为虚拟主机的首要主机名。 - - - -主机名中可以含有星号(“*”)，以替代名字的开始部分或结尾部分： - -server { - server_name example.com *.example.com www.example.*; -} - -上面这些名字称为通配符主机名。 - - - -上面例子中的前两个名字可以组合成一个： - -server { - server_name .example.com; -} - - - - -也可以在主机名中使用正则表达式，就是在名字前面补一个波浪线(“~”)： - -server { - server_name www.example.com ~^www\d+\.example\.com$; -} - - - - -可以在正则表达式中包含匹配组(0.7.40)，后续被其他指令使用： - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - -server { - server_name _; - - location / { - root /sites/default; - } -} - - - - - -正则表达式中的命名匹配组可以创建变量(0.8.25)，后续被其他指令使用： - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - -server { - server_name _; - - location / { - root /sites/default; - } -} - - - - -如果参数值等于“$hostname”(0.9.4)，将使用机器的hostname来替换。 - - - -nginx也允许定义空主机名(0.7.11)： - -server { - server_name www.example.com ""; -} - -这种主机名可以让虚拟主机处理没有
Host
请求头的请求，而不是让指定“地址:端口”的默认虚拟主机来处理。 -这是本指令的默认设置。 - -在0.8.48版以前，机器的hostname被用作默认设置。 - - - - -通过名字查找虚拟主机时，如果一个名字可以匹配多个指定的配置，比如同时匹配上通配符和正则表达式， -按下面优先级，使用先匹配上的虚拟主机： - - - -确切的名字； - - - -最长的以星号起始的通配符名字，比如“*.example.com”； - - - -最长的以星号结束的通配符名字，比如“mail.*”； - - - -第一个匹配的正则表达式名字（按在配置文件中出现的顺序）。 - - - - - - -另一篇文档“虚拟主机名”对虚拟主机名的有详细的描述。 - - - - - - -on | off -off -http -server -location - - -开启或关闭nginx将指令指定的首要虚拟主机名用于发起的重定向的功能。 -关闭此功能时，nginx将使用
Host
请求头的中的名字，如果没有此请求头，nginx将使用虚拟主机所在的IP地址。 - - - -重定向中端口的使用由指令控制。 - - - - - - -size -32|64|128 -http - - -设置主机名哈希表的表项长度，其默认值取决于处理器的缓存线长度。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - - - -size -512 -http - - -设置主机名哈希表的最大size(桶容量)。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - - - -on | off -on -http -server -location - - -开启或关闭在错误信息的
Server
响应头中输出nginx版本号。 - - - - - - -on | off -on -http -server -location - - -开启或关闭nginx使用TCP_NODELAY选项的功能。 -这个选项仅在将连接转变为长连接的时候才被启用。（译者注，在upstream发送响应到客户端时也会启用）。 - - - - - - -on | off -off -http -server -location - - -开启或者关闭nginx在FreeBSD上使用TCP_NOPUSH套接字选项， -在Linux上使用TCP_CORK套接字选项。 -选项仅在使用的时候才开启。 -开启此选项允许 - - - -在Linux和FreeBSD 4.*上将响应头和正文的开始部分一起发送； - - - -一次性发送整个文件。 - - - - - - - - - -file ... uri -file ... =code - -server -location - - -按指定顺序检查文件是否存在，并且使用第一个找到的文件来处理请求，那么处理过程就是在当前上下文环境中进行的。 -文件路径是根据指令和指令，将file参数拼接而成。 -可以在名字尾部添加斜线以检查目录是否存在，比如“$uri/”。 -如果找不到任何文件，将按最后一个参数指定的uri进行内部跳转。 -比如： - -location /images/ { - try_files $uri /images/default.gif; -} - -location = /images/default.gif { - expires 30s; -} - -最后一个参数也可以指向一个命名路径，如下面的例子所示。 -从0.7.51版开始，最后一个参数也可以是code： - -location / { - try_files $uri $uri/index.html $uri.html =404; -} - - - - -下面是代理Mongrel的例子： - -location / { - try_files /system/maintenance.html - $uri $uri/index.html $uri.html - @mongrel; -} - -location @mongrel { - proxy_pass http://mongrel; -} - - - - -下面是Drupal用FastCGI的例子： - -location / { - try_files $uri $uri/ @drupal; -} - -location ~ \.php$ { - try_files $uri @drupal; - - fastcgi_pass ...; - - fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name; - fastcgi_param SCRIPT_NAME $fastcgi_script_name; - fastcgi_param QUERY_STRING $args; - - ... other fastcgi_param's -} - -location @drupal { - fastcgi_pass ...; - - fastcgi_param SCRIPT_FILENAME /path/to/index.php; - fastcgi_param SCRIPT_NAME /index.php; - fastcgi_param QUERY_STRING q=$uri&$args; - - ... other fastcgi_param's -} - -而下面的例子中 - -location / { - try_files $uri $uri/ @drupal; -} - -try_files指令等价于 - -location / { - error_page 404 = @drupal; - log_not_found off; -} - -然后是这里， - -location ~ \.php$ { - try_files $uri @drupal; - - fastcgi_pass ...; - - fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name; - - ... -} - -try_files在将请求发送到FastCGI服务器以前检查PHP文件是否存在。 - - - -下面是Wordpress和Joomla的例子： - -location / { - try_files $uri $uri/ @wordpress; -} - -location ~ \.php$ { - try_files $uri @wordpress; - - fastcgi_pass ...; - - fastcgi_param SCRIPT_FILENAME /path/to$fastcgi_script_name; - ... other fastcgi_param's -} - -location @wordpress { - fastcgi_pass ...; - - fastcgi_param SCRIPT_FILENAME /path/to/index.php; - ... other fastcgi_param's -} - - - - - - - - - - text/html html; - image/gif gif; - image/jpeg jpg; - -http -server -location - - -设置文件扩展名和响应的MIME类型的映射表。 -可以将多个扩展名映射到同一种类型，比如： - -types { - application/octet-stream bin exe dll; - application/octet-stream deb; - application/octet-stream dmg; -} - - - - -随nginx发行的conf/mime.types文件中包含了足够全面的映射表。 - - - -为了是为某个路径的所有请求生成MIME类型“application/octet-stream”， -可以使用下面配置： - -location /download/ { - types { } - default_type application/octet-stream; -} - - - - - - - -size -32|64|128 -http -server -location - - -设置MIME类型哈希表的表项长度，其默认值取决于处理器的缓存线长度。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - - - -size -1024 -http -server -location - - -设置MIME类型哈希表的最大size(桶容量)。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - - - -on | off -off -http -server - - -允许或禁止在客户端请求头中使用下划线。 -如果禁止，含有下划线的请求头将被标志为非法请求头并接受指令的处理。 - - - -可以在默认主机的配置级别定义此命令。这样，指令设置将覆盖监听同一地址和端口的所有虚拟主机。 - - - - - - -size -64 -http - - -设置变量哈希表的表项长度，其默认值取决于处理器的缓存线长度。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - - - -size -512 -http - - -设置变量哈希表的最大size(桶容量)。 -另一篇文档“设置哈希表”详细介绍了如何设置哈希表。 - - - - -
- - -
- - -ngx_http_core_module模块支持内嵌变量，变量名与Apache服务器对应。 -首先，这些变量可以表示客户端的请求头字段，诸如$http_user_agent、$http_cookie等等。 -nginx也支持其他变量： - - -$arg_name - -请求行中的name参数。 - - -$args - -请求行中参数字符串。 - - -$binary_remote_addr - -客户端IP地址的二进制形式，值的长度总是4字节。 - - -$body_bytes_sent - -nginx返回给客户端的字节数，不含响应头。 - - -$bytes_sent - -nginx返回给客户端的字节数(1.3.8, 1.2.5)。 - - -$connection - -连接的序列号(1.3.8, 1.2.5)。 - - -$content_length - -
Content-Length
请求头的值。 - - -$content_type - -
Content-Type
请求头的值。 - - -$cookie_name - -名为name的cookie。 - - -$document_root - -当前请求的指令或指令的配置值。 - - -$document_uri - -与$uri相同。 - - -$host - -
Host
请求头的值，如果没有该请求头，则为与请求对应的虚拟主机的首要主机名。 - - -$hostname - -机器名称。 - - -$http_name - -任意请求头的值；变量名的后半部为转化为小写并且用下划线替代横线后的请求头名称。 - - -$https - -如果连接是SSL模块，返回“on”，否则返回空字符串。 - - -$is_args - -如果请求行带有参数，返回“?”，否则返回空字符串。 - - -$limit_rate - -允许设置此值来限制连接的传输速率。 - - -$msec - -当前时间，单位是秒，精度是毫秒。(1.3.9, 1.2.6) - - -$nginx_version - -nginx版本号。 - - -$pid - -worker进程的PID。 - - -$query_string - -与$args相同。 - - -$realpath_root - -按指令或指令算出的当前请求的绝对路径。其中的符号链接都会解析成真是文件路径。 - - -$remote_addr - -客户端IP地址。 - - -$remote_port - -客户端端口。 - - -$remote_user - -为基本用户认证提供的用户名。 - - -$request - -完整的原始请求行。 - - -$request_body - -请求正文。 - -在由指令和 -指令处理的路径中， -这个变量值可用。 - - - -$request_body_file - -请求正文的临时文件名。 - -处理完成时，临时文件将被删除。 -如果希望总是将请求正文写入文件，需要开启。 -如果在被代理的请求或FastCGI请求中传递临时文件名，就应该禁止传递请求正文本身。 -使用proxy_pass_request_body off指令 -和fastcgi_pass_request_body off指令 -分别禁止在代理和FastCGI中传递请求正文。 - - - -$request_completion - -请求完成时返回“OK”，否则返回空字符串。 - - -$request_filename - -基于指令或指令，以及请求URI，得到的当前请求的文件路径。 - - -$request_method - -HTTP方法，通常为“GET”或者“POST”。 - - -$request_time - -请求处理的时间，单位为秒，精度是毫秒(1.3.9, 1.2.6)；请求处理时间从由客户端接收到第一个字节开始计算。 - - -$request_uri - -完整的原始请求行（带参数）。 - - -$scheme - -请求协议类型，为“http”或“https”。 - - -$sent_http_name - -任意的响应头字段的值。 -变量名的后半部为转化为小写并且用下划线替代横线后的响应头名称。 - - -$server_addr - -接受请求的服务器地址。 - -为计算这个值，通常需要进行一次系统调用。为了避免系统调用，必须指定指令 -的地址，并且使用bind参数。 - - - -$server_name - -接受请求的虚拟主机的首要主机名。 - - -$server_port - -接受请求的虚拟主机的端口。 - - -$server_protocol - -请求协议，通常为“HTTP/1.0”或“HTTP/1.1”。 - - -$status - -响应状态码。 - - - -$tcpinfo_rtt, -$tcpinfo_rttvar, -$tcpinfo_snd_cwnd, -$tcpinfo_rcv_space - - -客户端TCP连接的信息，在支持套接字选项TCP_INFO的系统中可用。 - - -$uri - -当前请求规范化以后的URI。 - -变量$uri的值可能随请求的处理过程而改变。 -比如，当进行内部跳转时，或者使用默认页文件。 - - - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_empty_gif_module.xml b/xml/cn/docs/http/ngx_http_empty_gif_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_empty_gif_module.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - - - - - - -
- - -模块 ngx_http_empty_gif_module 只返回一个透明像素的GIF图片。 - - -
- - -
- - - -location = /_.gif { - empty_gif; -} - - - -
- - -
- - - - -location - - -在当前location里使用这个模块处理请求。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_flv_module.xml b/xml/cn/docs/http/ngx_http_flv_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_flv_module.xml +++ /dev/null @@ -1,65 +0,0 @@ - - - - - - - - -
- - -模块ngx_http_flv_module 为Flash Video(FLV)文件 -提供服务端伪流媒体支持 - - - -通过返回以请求偏移位置开始的文件内容，该模块专门处理 -在查询串中有start参数的请求, -和有预先设置到FLV头部的请求。 - - - -这个模块并不是默认构建的，必须通过配置参数 ---with-http_flv_module -来启用。 - - -
- - -
- - - -location ~ \.flv$ { - flv; -} - - - -
- - -
- - - -location - - -在当前location里使用这个模块处理请求。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_geo_module.xml b/xml/cn/docs/http/ngx_http_geo_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_geo_module.xml +++ /dev/null @@ -1,152 +0,0 @@ - - - - - - - - -
- - -ngx_http_geo_module 模块创建变量，并根据客户端IP地址对变量赋值。 - - -
- - -
- - - -geo $geo { - default 0; - 127.0.0.1/32 2; - 192.168.1.0/24 1; - 10.1.0.0/16 1; -} - - - -
- - -
- - -[$address] $variable - -http - - -定义从指定的变量获取客户端的IP地址。默认情况下，nginx从$remote_addr变量取得客户端IP地址，但也可以从其他变量获得（0.7.27版），比如： - -geo $arg_remote_addr $geo { - ...; -} - -如果该变量的值不能代表一个合法的IP地址，那么nginx将使用地址“255.255.255.255”。 - - - -nginx通过CIDR或者地址段（0.7.23版）来描述地址，同时支持下面的特殊参数： - - -delete - -删除指定网络（0.7.23版）。 - - -default - -如果客户端地址不能匹配任意一个定义的地址，nginx将使用此值。 -如果使用CIDR，可以用“0.0.0.0/0”代替default。 - - -include - -包含一个定义地址和值的文件。可以多次包含。 - - -proxy - -定义可信地址（0.8.7，0.7.63版）。 -如果请求来自可信地址，nginx将使用其
X-Forwarded-For
头来获得地址。 -相对于普通地址，可信地址是顺序检测的。 - -从1.3.0和1.2.1版本起，nginx开始支持IPv6地址。 - - - -proxy_recursive - -开启递归查找地址（1.3.0，1.2.1版）。 -如果关闭递归查找，在客户端地址与某个可信地址匹配时，nginx将使用
X-Forwarded-For
中的最后一个地址来代替原始客户端地址。 -如果开启递归查找，在客户端地址与某个可信地址匹配时，nginx将使用
X-Forwarded-For
中最后一个与所有可信地址都不匹配的地址来代替原始客户端地址。 - - -ranges - -指示地址将定义为地址段的形式（0.7.23版）。这个参数应该第一个被定义。为了加速装载地址库，地址应按升序定义。 - - - - - - -举例： - -geo $country { - default ZZ; - include conf/geo.conf; - delete 127.0.0.0/16; - proxy 192.168.100.0/24; - proxy 2001:0db8::/32; - - 127.0.0.0/24 US; - 127.0.0.1/32 RU; - 10.1.0.0/16 RU; - 192.168.1.0/24 UK; -} - - - - -conf/geo.conf文件中可能包含下列文本行： - -10.2.0.0/16 RU; -192.168.2.0/24 RU; - - - - -nginx将使用能最精确匹配客户端地址的配置中定义的值。比如，对于地址127.0.0.1，nginx会选取“RU”而非“US”，作为变量值。 - - - -地址段的例子： - -geo $country { - ranges; - default ZZ; - 127.0.0.0-127.0.0.0 US; - 127.0.0.1-127.0.0.1 RU; - 127.0.0.1-127.0.0.255 US; - 10.1.0.0-10.1.255.255 RU; - 192.168.1.0-192.168.1.255 UK; -} - - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_geoip_module.xml b/xml/cn/docs/http/ngx_http_geoip_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_geoip_module.xml +++ /dev/null @@ -1,167 +0,0 @@ - - - - - - - - -
- - -ngx_http_geoip_module 模块（0.8.6+）创建变量，使用预编译的MaxMind数据库解析客户端IP地址，得到变量值。 - - - -nginx默认不编译这个模块，需要开启--with-http_geoip_module编译选项。 - -模块依赖MaxMind GeoIP库。 - - - -
- - -
- - - -http { - geoip_country GeoIP.dat; - geoip_city GeoLiteCity.dat; - geoip_proxy 192.168.100.0/24; - geoip_proxy 2001:0db8::/32; - geoip_proxy_recursive on; - ... - - - -
- - -
- - -database - -http - - -指定数据库，用于根据客户端IP地址得到其所在国家。 -使用这个数据库时，配置中可用下列变量： - - -$geoip_country_code - -双字符国家代码，比如 -“RU”，“US”。 - - -$geoip_country_code3 - -三字符国家代码，比如 -“RUS”，“USA”。 - - -$geoip_country_name - -国家名称，比如 -“Russian Federation”，“United States”。 - - - - - - - - - -database - -http - - -指定数据库，用于根据客户端IP地址得到其所在的国家、行政区和城市。 -使用这个数据库时，配置中可用下列变量： - - -$geoip_city_country_code - -双字符国家代码，比如 -“RU”，“US”。 - - -$geoip_city_country_code3 - -三字符国家代码，比如 -“RUS”，“USA”。 - - -$geoip_city_country_name - -国家名称，比如 -“Russian Federation”，“United States”。 - - -$geoip_region - -国家行政区名（行政区、直辖区、州、省、联邦管辖区，诸如此类），比如 -“Moscow City”，“DC”。 - - -$geoip_city - -城市名称，比如 -“Moscow”，“Washington”。 - - -$geoip_postal_code - -邮编。 - - - - - - - - - -address | CIDR - -http -1.3.0 -1.2.1 - - -定义可信地址。 -如果请求来自可信地址，nginx将使用其
X-Forwarded-For
头来获得地址。 - - - - - - -on | off -off -http -1.3.0 -1.2.1 - - -如果关闭递归查找，在客户端地址与某个可信地址匹配时，nginx将使用
X-Forwarded-For
中的最后一个地址来代替原始客户端地址。 -如果开启递归查找，在客户端地址与某个可信地址匹配时，nginx将使用
X-Forwarded-For
中最后一个与所有可信地址都不匹配的地址来代替原始客户端地址。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_gzip_static_module.xml b/xml/cn/docs/http/ngx_http_gzip_static_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_gzip_static_module.xml +++ /dev/null @@ -1,70 +0,0 @@ - - - - - - - - -
- - -模块 ngx_http_gzip_static_module 允许发送以“.gz”作为文件扩展名的预压缩文件，以替代发送普通文件。 - - - -这个模块不是默认编译的，因此需要指定 ---with-http_gzip_static_module -编译选项。 - - -
- - -
- - - -gzip_static on; -gzip_proxied expired no-cache no-store private auth; - - - -
- - -
- - -on | off -off -http -server -location - - -启用或者禁用检查预压缩文件是否存在。 -与以下指令共同确定功能开启: -, -, -, -和. - - - -文件可以使用 gzip 命令来进行压缩，或任何其他兼容的命令。 -建议压缩文件和原始文件的修改日期和时间保持一致。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_image_filter_module.xml b/xml/cn/docs/http/ngx_http_image_filter_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_image_filter_module.xml +++ /dev/null @@ -1,219 +0,0 @@ - - - - - - - - -
- - -ngx_http_image_filter_module 模块（0.7.54+）是一个 -过滤器，它可以对JPEG,GIF和PNG等图像进行变换。 - - - -这个模块并不是默认编译的，需要通过 ---with-http_image_filter_module编译选项来启用。 - -这个模块使用了 -libgd 库。 -推荐使用这个库可用的最新版本；在写这个文档时它的最新版本是2.0.35。 - - - -
- - -
- - - -location /img/ { - proxy_pass http://backend; - image_filter resize 150 100; - image_filter rotate 90; - error_page 415 = /empty; -} - -location = /empty { - empty_gif; -} - - - -
- - -
- - -off -test -size - - rotate - 90 | 180 | - 270 - - resize - width - height - - crop - width - height - -location - - -设置图像变换的操作： - - -off - -在所在location关闭模块处理。 - - -test - -确保应答是JPEG，GIF或PNG格式的图像。否则错误 - -将被返回。 - - -size - -以JSON格式返回图像信息。例如： - -{ "img" : { "width": 100, "height": 100, "type": "gif" } } - -如果有错误发生，将会返回如下： - -{} - - - -rotate -90|180|270 - - -将图像逆时针旋转指定角度。 -参数的值可以包含变量。 -可以单独使用，或与 -resize 和 crop 变换同时使用. - - -resize -width -height - - -按比例缩小图像至指定大小。 -如果想只指定其中一维，另一维可以指定为： -“-”。 -如果有错误发生，服务器会返回 -. -参数的值可以包含变量。 -当与 rotate 参数同时使用时, -旋转发生在缩放 之后。 - - -crop -width -height - - -按比例以图像的最短边为准对图像大小进行缩小，然后裁剪另一边多出来的部分。 -如果想只指定其中一维，另一维可以指定为： -“-”。 -如果有错误发生，服务器会返回 -. -参数的值可以包含变量。 -当与 rotate 参数同时使用时, -旋转发生在裁剪 之前。 - - - - - - - - - -size -1M -http -server -location - - -设置用来读图像的缓冲区的最大值。 -若图像超过这个大小，服务器会返回 -. - - - - - - -quality -75 -http -server -location - - -设置变换后的JPEG图像的 质量 。 -可配置值： 1 ~ 100 。 -更小的值意味着更差的图像质量以及更少需要传输的数据。 -推荐的最大值是95. -参数的值可以包含变量。 - - - - - - -percent -0 -http -server -location - - -增加最终图像的锐度。 -锐度百分比可以超过100. -0为关闭锐化。 -参数的值可以包含变量。 - - - - - - -on|off -on -http -server -location - - -定义当对PNG，或者GIF图像进行颜色变换时是否需要保留透明度。 -损失透明度有可能可以获得更高的图像质量。 -PNG图像中的alpha通道的透明度默认会一直被保留。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_index_module.xml b/xml/cn/docs/http/ngx_http_index_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_index_module.xml +++ /dev/null @@ -1,77 +0,0 @@ - - - - - - - - -
- - -模块 ngx_http_index_module 处理以斜线字符(‘/’)结尾的请求。 - - -
- - -
- - - -location / { - index index.$geo.html index.html; -} - - - -
- - -
- - -file ... -index.html -http -server -location - - -定义将要被作为默认页的文件。 -文件 file 的名字可以包含变量。 -文件以配置中指定的顺序被nginx检查。 -列表中的最后一个元素可以是一个带有绝对路径的文件。 -例子： - -index index.$geo.html index.0.html /index.html; - - - - -需要注意的是，index文件会引发内部重定向，请求可能会被其它location处理。 -比如，下面这个例子： - -location = / { - index index.html; -} - -location / { - ... -} - -请求“/”实际上将会在第二个location中作为“/index.html”被处理。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_limit_conn_module.xml b/xml/cn/docs/http/ngx_http_limit_conn_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_limit_conn_module.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - - - - - -
- - -ngx_http_limit_conn_module 模块可以按照定义的键限定每个键值的连接数。特别的，可以设定单一 IP 来源的连接数。 - - - -并不是所有的连接都会被模块计数；只有那些正在被处理的请求（这些请求的头信息已被完全读入）所在的连接才会被计数。 - - -
- - -
- - - -http { - limit_conn_zone $binary_remote_addr zone=addr:10m; - - ... - - server { - - ... - - location /download/ { - limit_conn addr 1; - } - - - -
- - -
- - -zone number - -http -server -location - - -指定一块已经设定的共享内存空间，以及每个给定键值的最大连接数。当连接数超过最大连接数时，服务器将会返回 - -错误。比如，如下配置 - -limit_conn_zone $binary_remote_addr zone=addr:10m; - -server { - location /download/ { - limit_conn addr 1; - } - -表示，同一 IP 同一时间只允许有一个连接。 - - - -当多个 limit_conn 指令被配置时，所有的连接数限制都会生效。比如，下面配置不仅会限制单一IP来源的连接数，同时也会限制单一虚拟服务器的总连接数： - -limit_conn_zone $binary_remote_addr zone=perip:10m; -limit_conn_zone $server_name zone=perserver:10m; - -server { - ... - limit_conn perip 10; - limit_conn perserver 100; -} - - - - - -如果当前配置层级没有limit_conn指令，将会从更高层级继承连接限制配置。 - - - - - - - -info | -notice | -warn | -error -error -http -server -location -0.8.18 - - -指定当连接数超过设定的最大连接数，服务器限制连接时的日志等级。 - - - - - - - - $variable - zone=name:size - -http - - -设定保存各个键的状态的共享内存空间的参数。键的状态中保存了当前连接数。键的值可以是特定变量的任何非空值（空值将不会被考虑）。 -使用范例： - -limit_conn_zone $binary_remote_addr zone=addr:10m; - -这里，设置客户端的IP地址作为键。注意，这里使用的是$binary_remote_addr变量，而不是$remote_addr变量。$remote_addr变量的长度为7字节到15字节不等，而存储状态在32位平台中占用32字节或64字节，在64位平台中占用64字节。而$binary_remote_addr变量的长度是固定的4字节，存储状态在32位平台中占用32字节或64字节，在64位平台中占用64字节。一兆字节的共享内存空间可以保存3.2万个32位的状态，1.6万个64位的状态。如果共享内存空间被耗尽，服务器将会对后续所有的请求返回 - -错误。 - - - - - - - - name - $variable - size - -http - - -这条指令在 1.1.8 版本中已经被废弃，应该使用等效的指令。该指令的语法也有变化： - -limit_conn_zone -$variable -zone=name:size; - - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_limit_req_module.xml b/xml/cn/docs/http/ngx_http_limit_req_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_limit_req_module.xml +++ /dev/null @@ -1,153 +0,0 @@ - - - - - - - - -
- - -ngx_http_limit_req_module模块(0.7.21)可以通过定义的 -键值来限制请求处理的频率。特别的，它可以限制来自单个IP地址的请求处理频率。 -限制的方法是通过一种“漏桶”的方法——固定每秒处理的请求数，推迟过多的请求处理。 - - - -
- - -
- - - -http { - limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; - - ... - - server { - - ... - - location /search/ { - limit_req zone=one burst=5; - } - - - -
- - -
- - - - zone=name - [burst=number] - [nodelay] - -http -server -location - - -设置对应的共享内存限制域和允许被处理的最大请求数阈值。 -如果请求的频率超过了限制域配置的值，请求处理会被延迟，所以 -所有的请求都是以定义的频率被处理的。 -超过频率限制的请求会被延迟，直到被延迟的请求数超过了定义的阈值 -这时，这个请求会被终止，并返回 -错误。这个阈值的默认值等于0。 -比如这些指令： - -limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; - -server { - location /search/ { - limit_req zone=one burst=5; - } - -限制平均每秒不超过一个请求，同时允许超过频率限制的请求数不多于5个。 - - - -如果不希望超过的请求被延迟，可以用nodelay参数： - -limit_req zone=one burst=5 nodelay; - - - - - - - - -info | -notice | -warn | -error -error -http -server -location -0.8.18 - - -设置你所希望的日志级别，当服务器因为频率过高拒绝或者延迟处理请求时可以记下相应级别的日志。 -延迟记录的日志级别比拒绝的低一个级别；比如， -如果设置“limit_req_log_level notice”， -延迟的日志就是info级别。 - - - - - - - - $variable - zone=name:size - rate=rate - -http - - -设置一块共享内存限制域的参数，它可以用来保存键值的状态。 -它特别保存了当前超出请求的数量。 -键的值就是指定的变量（空值不会被计算）。 -示例用法： - -limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s; - - - - -这里，状态被存在名为“one”，最大10M字节的共享内存里面。对于这个限制域来说 -平均处理的请求频率不能超过每秒一次。 - - - -键值是客户端的IP地址。 -如果不使用$remote_addr变量，而用$binary_remote_addr变量， -可以将每条状态记录的大小减少到64个字节，这样1M的内存可以保存大约1万6千个64字节的记录。 -如果限制域的存储空间耗尽了，对于后续所有请求，服务器都会返回 -错误。 - - - -请求频率可以设置为每秒几次（r/s）。如果请求的频率不到每秒一次， -你可以设置每分钟几次(r/m)。比如每秒半次就是30r/m。 - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_log_module.xml b/xml/cn/docs/http/ngx_http_log_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_log_module.xml +++ /dev/null @@ -1,266 +0,0 @@ - - - - - - - - -
- - -ngx_http_log_module模块按指定的格式写访问日志。 - - - -请求在处理结束时，会按请求路径的配置上下文记访问日志。 -如果在请求处理期间产生了内部跳转， -请求结束时的路径可能不同于原始的请求路径。 - - -
- - -
- - - -log_format gzip '$remote_addr - $remote_user [$time_local] ' - '"$request" $status $bytes_sent ' - '"$http_referer" "$http_user_agent" "$gzip_ratio"'; - -access_log /spool/logs/nginx-access.log gzip buffer=32k; - - - -
- - -
- - - - path - [format - [buffer=size]] -off -logs/access.log combined -http -server -location -if in location -limit_except - - -为访问日志设置路径，格式和缓冲区大小（nginx访问日志支持缓存）。 -在同一个配置层级里可以指定多个日志。 -特定值off会取消当前配置层级里的所有access_log指令。 -如果没有指定日志格式则会使用预定义的“combined”格式。 - - - -缓冲区的大小不能超过磁盘文件原子性写入的大小。 -对于FreeBSD来说缓冲区大小是无限制的。 - - - -日志文件的路径可以包含变量（0.7.6+）， -但此类日志存在一些限制： - - - -工作进程使用的 -应拥有在目录里创建文件的权限； - - - -写缓冲无效； - - - -每条日志写入都会打开和关闭文件。然而，频繁使用的文件描述符可以存储在 -缓存中， -在指令的valid参数指定的时间里， -写操作能持续写到旧文件。 - - - -每次日志写入的操作都会检查请求的 -根目录是否存在， -如果不存在则日志不会被创建。 -因此在一个层级里同时指定 -和access_log是一个不错的想法： - -server { - root /spool/vhost/data/$host; - access_log /spool/vhost/logs/$host; - ... - - - - - - - - - - - - name - string ... -combined "..." -http - - -指定日志的格式。 - - - -日志格式允许包含普通变量和只在日志写入时存在的变量： - - -$body_bytes_sent - -发送给客户端的字节数，不包括响应头的大小； -该变量与Apache模块mod_log_config里的“%B”参数兼容。 - - -$bytes_sent - -发送给客户端的总字节数。 - - -$connection - -连接的序列号。 - - -$connection_requests - -当前通过一个连接获得的请求数量。 - - -$msec - -日志写入时间。单位为秒，精度是毫秒。 - - -$pipe - -如果请求是通过HTTP流水线(pipelined)发送，pipe值为“p”，否则为“.”。 - - -$request_length - -请求的长度（包括请求行，请求头和请求正文）。 - - -$request_time - -请求处理时间，单位为秒，精度毫秒； -从读入客户端的第一个字节开始，直到把最后一个字符发送给客户端后进行日志写入为止。 - - -$status - -响应状态。 - - -$time_iso8601 - -ISO8601标准格式下的本地时间。 - - -$time_local - -通用日志格式下的本地时间。 - - - - - - -发送给客户端的响应头拥有“sent_http_”前缀。 -比如$sent_http_content_range。 - - - -配置始终包含预先定义的“combined”日志格式： - -log_format combined '$remote_addr - $remote_user [$time_local] ' - '"$request" $status $body_bytes_sent ' - '"$http_referer" "$http_user_agent"'; - - - - - - - - - -max=N -[inactive=time] -[min_uses=N] -[valid=time] -off -off -http -server -location - - -定义一个缓存，用来存储频繁使用的文件名中包含变量的日志文件描述符。 -该指令包含以下参数： - - -max - -设置缓存中描述符的最大数量；如果缓存被占满，最近最少使用（LRU）的描述符将被关闭。 - - -inactive - -设置缓存文件描述符在多长时间内没有被访问就关闭； -默认为10秒。 - - -min_uses - -设置在inactive参数指定的时间里， -最少访问多少次才能使文件描述符保留在缓存中；默认为1。 - - -valid - -设置一段用于检查超时后文件是否仍以同样名字存在的时间； -默认为60秒。 - - -off - -禁用缓存。 - - - - - - -使用实例： - -open_log_file_cache max=1000 inactive=20s valid=1m min_uses=2; - - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_map_module.xml b/xml/cn/docs/http/ngx_http_map_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_map_module.xml +++ /dev/null @@ -1,186 +0,0 @@ - - - - - - - - -
- - -模块 ngx_http_map_module 可以创建一些和另外变量相关联的变量。 - - -
- - -
- - - -map $http_host $name { - hostnames; - - default 0; - - example.com 1; - *.example.com 1; - example.org 2; - *.example.org 2; - .example.net 3; - wap.* 4; -} - -map $http_user_agent $mobile { - default 0; - "~Opera Mini" 1; -} - - - -
- - -
- - - - string - $variable - -http - - -在配置的参数中，第一个是要创建新的变量，它的值取决于后面一个或多个源变量。 - -在0.9.0版本之前，这里只支持一个变量。 - - - - -在 map 块里的参数指定了源变量值和结果值的对应关系。 - - - -源变量值可以使用字符串或者正则表达式 (0.9.6)。 - - - -一个正则表达式如果以 “~” 开头，这个正则表达式对大小写敏感； -若以 “~*”开头 (1.0.4)，这个正则表达式对大小写不敏感。 -且正则表达式里可以包含命名捕获和位置捕获，这些变量可以跟结果变量一起被其它指令使用。 - - - -如果源变量的值正好跟特殊参数同名（看下面），它要以 “\” 字符作为前缀。 - - - -结果变量可以是一个字符串也可以是另外一个变量 (0.9.0)。 - - - -这个指令也支持三个特殊参数。 - -default value - -如果源变量值没有匹配到任何变量，则设置一个默认值作为结果。 -当没有设置 default，将会用一个空的字符串作为默认的结果。 - - -hostnames - -允许用前缀或者后缀掩码指定域名作为源变量值，举个例子， - -*.example.com 1; -example.* 1; - -这两条记录 - -example.com 1; -*.example.com 1; - -可以被合并为： - -.example.com 1; - -这个参数必须写在值映射列表的最前面。 - - -include file - -包含一个或者多个存有映射值的文件。 - - - - - - -如果源值匹配了多余一个的指定变量，例如掩码和正则同时匹配，那么将会按照下面的顺序进行优先选择： - - - -没有掩码的字符串 - - - -最长的带前缀的字符串，例如: “*.example.com” - - - -最长的带后缀的字符串，例如：“mail.*” - - - -按顺序第一个先匹配的正则表达式 （在配置文件中体现的顺序） - - - -默认值 - - - - - - - - - -size -32|64|128 -http - - -为 的变量哈稀表设置桶大小。 -默认值取决于处理器cache line的大小。 -可以从这里获取到更多参考信息： -设置哈稀表. - - - - - - -size -2048 -http - - -设置 变量哈稀表大小的上限。 -可以从这里获取到更多参考信息： -设置哈稀表. - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_proxy_module.xml b/xml/cn/docs/http/ngx_http_proxy_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_proxy_module.xml +++ /dev/null @@ -1,1103 +0,0 @@ - - - - - - - - -
- - -ngx_http_proxy_module 模块允许传送请求到其它服务器。 - - -
- - -
- - - -location / { - proxy_pass http://localhost:8000; - proxy_set_header Host $host; - proxy_set_header X-Real-IP $remote_addr; -} - - - -
- - -
- - -size -4k|8k -http -server -location - - -设置缓冲区的大小为size。nginx从被代理的服务器读取响应时，使用该缓冲区保存响应的开始部分。这部分通常包含着一个小小的响应头。该缓冲区大小默认等于指令设置的一块缓冲区的大小，但它也可以被设置得更小。 - - - - - - -on | off -on -http -server -location - - -代理的时候，开启或关闭缓冲后端服务器的响应。 - - - -当开启缓冲时，nginx尽可能快地从被代理的服务器接收响应，再将它存入和指令设置的缓冲区中。如果响应无法整个纳入内存，那么其中一部分将存入磁盘上的临时文件。和指令可以控制临时文件的写入。 - - - -当关闭缓冲时，收到响应后，nginx立即将其同步传给客户端。nginx不会尝试从被代理的服务器读取整个请求，而是将指令设定的大小作为一次读取的最大长度。 - - - -响应头
X-Accel-Buffering
传递“yes”或“no”可以动态地开启或关闭代理的缓冲功能。 -这个能力可以通过指令关闭。 - - - - - - -number size -8 4k|8k -http -server -location - - -为每个连接设置缓冲区的数量为number，每块缓冲区的大小为size。这些缓冲区用于保存从被代理的服务器读取的响应。每块缓冲区默认等于一个内存页的大小。这个值是4K还是8K，取决于平台。 - - - - - - -size -8k|16k -http -server -location - - -当开启缓冲响应的功能以后，在没有读到全部响应的情况下，写缓冲到达一定大小时，nginx一定会向客户端发送响应，直到缓冲小于此值。这条指令用来设置此值。 -同时，剩余的缓冲区可以用于接收响应，如果需要，一部分内容将缓冲到临时文件。该大小默认是和指令设置单块缓冲大小的两倍。 - - - - - - -zone | off -off -http -server -location - - -指定用于页面缓存的共享内存。同一块共享内存可以在多个地方使用。off参数可以屏蔽从上层配置继承的缓存功能。 - - - - - - -string ... - -http -server -location - - -定义nginx不从缓存取响应的条件。如果至少一个字符串条件非空而且非“0”，nginx就不会从缓存中去取响应： - -proxy_cache_bypass $cookie_nocache $arg_nocache$arg_comment; -proxy_cache_bypass $http_pragma $http_authorization; - -本指令可和与一起使用。 - - - - - - -string -$scheme$proxy_host$request_uri -http -server -location - - -定义如何生成缓存的键，比如 - -proxy_cache_key "$host$request_uri $cookie_user"; - -这条指令的默认值类似于下面字符串 - -proxy_cache_key $scheme$proxy_host$uri$is_args$args; - - - - - - - -on | off -off -http -server -location -1.1.12 - - -开启此功能时，对于相同的请求，同时只允许一个请求发往后端，并根据指令的设置在缓存中植入一个新条目。 -其他请求相同条目的请求将一直等待，直到缓存中出现相应的内容，或者锁在指令设置的超时后被释放。 - - - - - - -time -5s -http -server -location -1.1.12 - - -为指令设置锁的超时。 - - - - - - -number -1 -http -server -location - - -设置响应被缓存的最小请求次数。 - - - - - - - - path - [levels=levels] - keys_zone=name:size - [inactive=time] - [max_size=size] - [loader_files=number] - [loader_sleep=time] - [loader_threshold=time] - -http - - -设置缓存的路径和其他参数。缓存数据是保存在文件中的，缓存的键和文件名都是在代理URL上执行MD5的结果。 - -levels参数定义了缓存的层次结构。比如，下面配置 - -proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m; - -缓存中文件名看起来是这样的： - -/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c - - - - -被缓存的响应首先写入一个临时文件，然后进行重命名。从0.8.9版本开始，临时文件和缓存可以放在不同的文件系统。但请注意，这将导致文件在这两个文件系统中进行拷贝，而不是廉价的重命名操作。因此，针对任何路径，都建议将缓存和指令设置的临时文件目录放在同一文件系统。 - - - -此外，所有活动的键和缓存数据相关的信息都被存放在共享内存中。共享内存通过keys_zone参数的name和size来定义。被缓存的数据如果在inactive参数指定的时间内未被访问，就会被从缓存中移除，不论它是否是刚产生的。inactive的默认值是10分钟。 - - - -特殊进程“cache manager”监控缓存的条目数量，如果超过max_size参数设置的最大值，使用LRU算法移除缓存数据。 - - - -nginx新启动后不就，特殊进程“cache loader”就被启动。该进程将文件系统上保存的过去缓存的数据的相关信息重新加载到共享内存。加载过程分多次迭代完成，每次迭代，进程只加载不多于loader_files参数指定的文件数量（默认值为100）。此外，每次迭代过程的持续时间不能超过loader_threshold参数的值（默认200毫秒）。每次迭代之间，nginx的暂停时间由loader_sleep参数指定（默认50毫秒）。 - - - - - - - - error | - timeout | - invalid_header | - updating | - http_500 | - http_502 | - http_503 | - http_504 | - http_404 | - off - ... -off -http -server -location - - -如果后端服务器出现状况，nginx是可以使用过期的响应缓存的。这条指令就是定义何种条件下允许开启此机制。这条指令的参数与指令的参数相同。 - - - -此外，updating参数允许nginx在正在更新缓存的情况下使用过期的缓存作为响应。这样做可以使更新缓存数据时，访问源服务器的次数最少。 - - - -在植入新的缓存条目时，如果想使访问源服务器的次数最少，可以使用指令。 - - - - - - -[code ...] time - -http -server -location - - -为不同的响应状态码设置不同的缓存时间。比如，下面指令 - -proxy_cache_valid 200 302 10m; -proxy_cache_valid 404 1m; - -设置状态码为200和302的响应的缓存时间为10分钟，状态码为404的响应的缓存时间为1分钟。 - - - -如果仅仅指定了time， - -proxy_cache_valid 5m; - -那么只有状态码为200、300和302的响应会被缓存。 - - - -如果使用了any参数，那么就可以缓存任何响应： - -proxy_cache_valid 200 302 10m; -proxy_cache_valid 301 1h; -proxy_cache_valid any 1m; - - - - -缓存参数也可以直接在响应头中设定。这种方式的优先级高于使用这条指令设置缓存时间。 -
X-Accel-Expires
响应头可以以秒为单位设置响应的缓存时间，如果值为0，表示禁止缓存响应，如果值以@开始，表示自1970年1月1日以来的秒数，响应一直会被缓存到这个绝对时间点。 -如果不含
X-Accel-Expires
响应头，缓存参数仍可能被
Expires
或者
Cache-Control
响应头设置。 -如果响应头含有
Set-Cookie
，响应将不能被缓存。 -这些头的处理过程可以使用指令忽略。 - - - - - - -time -60s -http -server -location - - -设置与后端服务器建立连接的超时时间。应该注意这个超时一般不可能大于75秒。 - - - - - - -off -domain replacement -off -http -server -location -1.1.15 - - -设置
Set-Cookie
响应头中的domain属性的替换文本。 -假设后端服务器返回的
Set-Cookie
响应头含有属性“domain=localhost”，那么指令 - -proxy_cookie_domain localhost example.org; - -将这个属性改写为“domain=example.org”。 - - - -domain和replacement配置字符串，以及domain属性中起始的点将被忽略。 -匹配过程大小写不敏感。 - - - -domain和replacement配置字符串中可以包含变量： - -proxy_cookie_domain www.$host $host; - - - - -这条指令同样可以使用正则表达式。这时，domain应以“~”标志开始，且可以使用命名匹配组和位置匹配组，而replacement可以引用这些匹配组： - -proxy_cookie_domain ~\.(?P<sl_domain>[-0-9a-z]+\.[a-z]+)$ $sl_domain; - - - - -可以同时定义多条proxy_cookie_domain指令： - -proxy_cookie_domain localhost example.org; -proxy_cookie_domain ~\.([a-z]+\.[a-z]+)$ $1; - - - - -off参数可以取消当前配置级别的所有proxy_cookie_domain指令： - -proxy_cookie_domain off; -proxy_cookie_domain localhost example.org; -proxy_cookie_domain www.example.org example.org; - - - - - - - -off -path replacement -off -http -server -location -1.1.15 - - -设置
Set-Cookie
响应头中的path属性的替换文本。 -假设后端服务器返回的
Set-Cookie
响应头含有属性“path=/two/some/uri/”，那么指令 - -proxy_cookie_path /two/ /; - -将这个属性改写为“path=/some/uri/”。 - - - -path和replacement配置字符串可以包含变量： - -proxy_cookie_path $uri /some$uri; - - - - -这条指令同样可以使用正则表达式。如果使用大小写敏感的匹配，path应以“~”标志开始，如果使用大小写不敏感的匹配，path应以“~*”标志开始。path可以使用命名匹配组和位置匹配组，replacement可以引用这些匹配组： - -proxy_cookie_path ~*^/user/([^/]+) /u/$1; - - - - -可以同时定义多条proxy_cookie_path指令： - -proxy_cookie_path /one/ /; -proxy_cookie_path / /two/; - - - - -off参数可以取消当前配置级别的所有proxy_cookie_path指令： - -proxy_cookie_path off; -proxy_cookie_path /two/ /; -proxy_cookie_path ~*^/user/([^/]+) /u/$1; - - - - - - - -field - -http -server -location - - -nginx默认不会将
Date
、
Server
、
X-Pad
，和
X-Accel-...
响应头发送给客户端。proxy_hide_header指令则可以设置额外的响应头，这些响应头也不会发送给客户端。相反的，如果希望允许传递某些响应头给客户端，可以使用指令。 - - - - - - -1.0 | 1.1 -1.0 -http -server -location -1.1.4 - - -设置代理使用的HTTP协议版本。默认使用的版本是1.0，而1.1版本则推荐在使用连接时一起使用。 - - - - - - -on | off -off -http -server -location - - -决定当客户端在响应传输完成前就关闭连接时，nginx是否应关闭后端连接。 - - - - - - -field ... - -http -server -location - - -不处理后端服务器返回的指定响应头。下面的响应头可以被设置： -
X-Accel-Redirect
，
X-Accel-Expires
，
X-Accel-Limit-Rate
(1.1.6)，
X-Accel-Buffering
(1.1.6)， -
X-Accel-Charset
(1.1.6)，
Expires
，
Cache-Control
，和
Set-Cookie
(0.8.44)。 - - - -如果不被取消，这些头部的处理可能产生下面结果： - - - -
X-Accel-Expires
，
Expires
，
Cache-Control
，和
Set-Cookie
-设置响应缓存的参数； - - - -
X-Accel-Redirect
执行到指定URI的内部跳转； - - - -
X-Accel-Limit-Rate
设置响应到客户端的传输速率限制； - - - -
X-Accel-Buffering
启动或者关闭响应缓冲； - - - -
X-Accel-Charset
设置响应所需的字符集。 - - - - - - - - - -on | off -off -http -server -location - - -当后端服务器的响应状态码大于等于400时，决定是否直接将响应发送给客户端，亦或将响应转发给nginx由指令来处理。 - - - - - - -size -1024m -http -server -location - - -打开响应缓冲以后，如果整个响应不能存放在和指令设置的缓冲区内，部分响应可以存放在临时文件中。 -这条指令可以设置临时文件的最大容量。而每次写入临时文件的数据量则由指令定义。 - - - -将此值设置为0将禁止响应写入临时文件。 - - - - - - - - error | - timeout | - invalid_header | - http_500 | - http_502 | - http_503 | - http_504 | - http_404 | - off - ... -error timeout -http -server -location - - -指定在何种情况下一个失败的请求应该被发送到下一台后端服务器： - - -error -和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现错误； - -timeout -和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现超时； - -invalid_header -后端服务器返回空响应或者非法响应头； - -http_500 -后端服务器返回的响应状态码为500； - -http_502 -后端服务器返回的响应状态码为502； - -http_503 -后端服务器返回的响应状态码为503； - -http_504 -后端服务器返回的响应状态码为504； - -http_404 -后端服务器返回的响应状态码为404； - -off -停止将请求发送给下一台后端服务器。 - - - - - -需要理解一点的是，只有在没有向客户端发送任何数据以前，将请求转给下一台后端服务器才是可行的。也就是说，如果在传输响应到客户端时出现错误或者超时，这类错误是不可能恢复的。 - - - - - - -string ... - -http -server -location - - -定义nginx不将响应写入缓存的条件。如果至少一个字符串条件非空而且非“0”，nginx就不将响应存入缓存： - -proxy_no_cache $cookie_nocache $arg_nocache$arg_comment; -proxy_no_cache $http_pragma $http_authorization; - -这条指令可以和指令一起使用。 - - - - - - -URL - -location -if in location -limit_except - - -设置后端服务器的协议和地址，还可以设置可选的URI以定义本地路径和后端服务器的映射关系。 -这条指令可以设置的协议是“http”或者“https”，而地址既可以使用域名或者IP地址加端口（可选）的形式来定义： - -proxy_pass http://localhost:8000/uri/; - -又可以使用UNIX域套接字路径来定义。该路径接在“unix”字符串后面，两端由冒号所包围，比如： - -proxy_pass http://unix:/tmp/backend.socket:/uri/; - - - - -如果解析一个域名得到多个地址，所有的地址都会以轮转的方式被使用。当然，也可以使用服务器组来定义地址。 - - - -请求URI按下面规则传送给后端服务器： - - - -如果proxy_pass使用了URI，当传送请求到后端服务器时，规范化以后的请求路径与配置中的路径的匹配部分将被替换为指令中定义的URI： - -location /name/ { - proxy_pass http://127.0.0.1/remote/; -} - - - - -如果proxy_pass没有使用URI，传送到后端服务器的请求URI一般客户端发起的原始URI，如果nginx改变了请求URI，则传送的URI是nginx改变以后完整的规范化URI： - -location /some/path/ { - proxy_pass http://127.0.0.1; -} - - -在1.1.12版以前，如果proxy_pass没有使用URI，某些情况下，nginx改变URI以后，会错误地将原始URI而不是改变以后的URI发送到后端服务器。 - - - - - - -某些情况下，无法确定请求URI中应该被替换的部分： - - - -使用正则表达式定义路径。 - -这种情况下，指令不应该使用URI。 - - - - -在需要代理的路径中，使用指令改变了URI，但仍使用相同配置处理请求(break)： - -location /name/ { - rewrite /name/([^/]+) /users?name=$1 break; - proxy_pass http://127.0.0.1; -} - - -这种情况下，本指令设置的URI会被忽略，改变后的URI将被发送给后端服务器。 - - - - - - -后端服务器的地址，端口和URI中都可以使用变量： - -proxy_pass http://$host$uri; - -甚至像这样： - -proxy_pass $request; - - - - -这种情况下，后端服务器的地址将会在定义的服务器组中查找。如果查找不到，nginx使用来查找该地址。 - - - - - - -field - -http -server -location - - -允许传送被屏蔽的后端服务器响应头到客户端。 - - - - - - -time -60s -http -server -location - - -定义从后端服务器读取响应的超时。此超时是指相邻两次读操作之间的最长时间间隔，而不是整个响应传输完成的最长时间。如果后端服务器在超时时间段内没有传输任何数据，连接将被关闭。 - - - - - - -default -off -redirect replacement -default -http -server -location - - -设置后端服务器
Location
响应头和
Refresh
响应头的替换文本。 -假设后端服务器返回的响应头是 -“Location: http://localhost:8000/two/some/uri/”，那么指令 - -proxy_redirect http://localhost:8000/two/ http://frontend/one/; - -将把字符串改写为 -“Location: http://frontend/one/some/uri/”。 - - - -replacement字符串可以省略服务器名： - -proxy_redirect http://localhost:8000/two/ /; - -此时将使用代理服务器的主域名和端口号来替换。如果端口是80，可以不加。 - - - -用default参数指定的默认替换使用了和指令的参数。因此，下面两例配置等价： - -location /one/ { - proxy_pass http://upstream:port/two/; - proxy_redirect default; - - - -location /one/ { - proxy_pass http://upstream:port/two/; - proxy_redirect http://upstream:port/two/ /one/; - -而且因为同样的原因，指令使用变量时，不允许本指令使用default参数。 - - - -replacement字符串可以包含变量： - -proxy_redirect http://localhost:8000/ http://$host:$server_port/; - - - - -而redirect字符串从1.1.11版本开始也可以包含变量： - -proxy_redirect http://$proxy_host:8000/ /; - - - - -同时，从1.1.11版本开始，指令支持正则表达式。使用正则表达式的话，如果是大小写敏感的匹配，redirect以“~”作为开始，如果是大小写不敏感的匹配，redirect以“~*”作为开始。而且redirect的正则表达式中可以包含命名匹配组和位置匹配组，而在replacement中可以引用这些匹配组的值： - -proxy_redirect ~^(http://[^:]+):\d+(/.+)$ $1$2; -proxy_redirect ~*/user/([^/]+)/(.+)$ http://$1.example.com/$2; - - - - -除此以外，可以同时定义多个proxy_redirect指令： - -proxy_redirect default; -proxy_redirect http://localhost:8000/ /; -proxy_redirect http://www.example.com/ /; - - - - -另外，off参数可以使所有相同配置级别的proxy_redirect指令无效： - -proxy_redirect off; -proxy_redirect default; -proxy_redirect http://localhost:8000/ /; -proxy_redirect http://www.example.com/ /; - - - - -最后，使用这条指令也可以为地址为相对地址的重定向添加域名： - -proxy_redirect / /; - - - - - - - -time -60s -http -server -location - - -定义向后端服务器传输请求的超时。此超时是指相邻两次写操作之间的最长时间间隔，而不是整个请求传输完成的最长时间。如果后端服务器在超时时间段内没有接收到任何数据，连接将被关闭。 - - - - - - -field value -Host $proxy_host -Connection close -http -server -location - - -允许重新定义或者添加发往后端服务器的请求头。value可以包含文本、变量或者它们的组合。 -当且仅当当前配置级别中没有定义proxy_set_header指令时，会从上面的级别继承配置。 -默认情况下，只有两个请求头会被重新定义： - -proxy_set_header Host $proxy_host; -proxy_set_header Connection close; - - - - -如果不想改变请求头
Host
的值，可以这样来设置： - -proxy_set_header Host $http_host; - - - - -但是，如果客户端请求头中没有携带这个头部，那么传递到后端服务器的请求也不含这个头部。 -这种情况下，更好的方式是使用$host变量——它的值在请求包含
Host
请求头时为
Host
字段的值，在请求未携带
Host
请求头时为虚拟主机的主域名： - -proxy_set_header Host $host; - - - - -此外，服务器名可以和后端服务器的端口一起传送： - -proxy_set_header Host $host:$proxy_port; - - - - -如果某个请求头的值为空，那么这个请求头将不会传送给后端服务器： - -proxy_set_header Accept-Encoding ""; - - - - - - - -on | off -on -http -server -location - - -决定是否重用与后端服务器的SSL会话。如果日志中出现“SSL3_GET_FINISHED:digest check failed”错误，请尝试关闭会话重用。 - - - - - - - - on | - off | - string -off -http -server -location - - -开启将文件保存到磁盘上的功能。如果设置为on，nginx将文件保存在指令或指令设置的路径中。如果设置为off，nginx将关闭文件保存的功能。此外，保存的文件名也可以使用含变量的string参数来指定： - -proxy_store /data/www$original_uri; - - - - -保存文件的修改时间根据接收到的
Last-Modified
响应头来设置。响应都是先写到临时文件，然后进行重命名来生成的。从0.8.9版本开始，临时文件和持久化存储可以放在不同的文件系统，但是需要注意这时文件执行的是在两个文件系统间拷贝操作，而不是廉价的重命名操作。因此建议保存文件的路径和指令设置的临时文件的路径在同一个文件系统中。 - - - -这条指令可以用于创建静态无更改文件的本地拷贝，比如： - -location /images/ { - root /data/www; - open_file_cache_errors off; - error_page 404 = /fetch$uri; -} - -location /fetch/ { - internal; - - proxy_pass http://backend/; - proxy_store on; - proxy_store_access user:rw group:rw all:r; - proxy_temp_path /data/temp; - - alias /data/www/; -} - - - - -或者像这样： - -location /images/ { - root /data/www; - error_page 404 = @fetch; -} - -location @fetch { - internal; - - proxy_pass http://backend; - proxy_store on; - proxy_store_access user:rw group:rw all:r; - proxy_temp_path /data/temp; - - root /data/www; -} - - - - - - - -users:permissions ... -user:rw -http -server -location - - -设置新创建的文件和目录的访问权限，比如： - -proxy_store_access user:rw group:rw all:r; - - - - -如果指定了任何group或者all的访问权限，那么可以略去user的访问权限： - -proxy_store_access group:rw all:r; - - - - - - - -size -8k|16k -http -server -location - - -在开启缓冲后端服务器响应到临时文件的功能后，设置nginx每次写数据到临时文件的size(大小)限制。 -size的默认值是指令和指令定义的每块缓冲区大小的两倍， -而临时文件最大容量由指令设置。 - - - - - - - - path - [level1 - [level2 - [level3]]] -proxy_temp -http -server -location - - -定义从后端服务器接收的临时文件的存放路径，可以为临时文件路径定义至多三层子目录的目录树。 -比如，下面配置 - -proxy_temp_path /spool/nginx/proxy_temp 1 2; - -那么临时文件的路径看起来会是这样： - -/spool/nginx/proxy_temp/7/45/00000123457 - - - - - -
- - -
- - -ngx_http_proxy_module支持内嵌变量，可以用于在指令中构造请求头： - - -$proxy_host -后端服务器的主机名和端口； - -$proxy_port -后端服务器的端口； - -$proxy_add_x_forwarded_for -将$remote_addr变量值添加在客户端
X-Forwarded-For
请求头的后面，并以逗号分隔。 -如果客户端请求未携带
X-Forwarded-For
请求头，$proxy_add_x_forwarded_for变量值将与$remote_addr变量相同。 - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_referer_module.xml b/xml/cn/docs/http/ngx_http_referer_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_referer_module.xml +++ /dev/null @@ -1,141 +0,0 @@ - - - - - - - - -
- - -ngx_http_referer_module模块允许拦截
Referer
请求头中含有非法值的请求，阻止它们访问站点。 -需要注意的是伪造一个有效的
Referer
请求头是相当容易的， -因此这个模块的预期目的不在于彻底地阻止这些非法请求，而是为了阻止由正常浏览器发出的大规模此类请求。 -还有一点需要注意，即使正常浏览器发送的合法请求，也可能没有
Referer
请求头。 - - -
- - -
- - - -valid_referers none blocked server_names - *.example.com example.* www.example.org/galleries/ - ~\.google\.; - -if ($invalid_referer) { - return 403; -} - - - -
- - -
- - -size -64 -server -location -1.0.5 - - -设置用来存储有效referer的哈希表的表项长度。 -详细的情况参见哈希表设置。 - - - - - - -size -2048 -server -location -1.0.5 - - -设置用来存储有效referer的哈希表最大桶容量。 -详细的情况参见哈希表设置。 - - - - - - - - none | - blocked | - server_names | - string - ... - -server -location - - -
Referer
请求头为指定值时，内嵌变量$invalid_referer被设置为空字符串， -否则这个变量会被置成“1”。查找匹配时不区分大小写。 - - - -该指令的参数可以为下面的内容： - - -none - -缺少
Referer
请求头； - - -blocked - -
Referer
请求头存在，但是它的值被防火墙或者代理服务器删除； -这些值都不以“http://” 或者 “https://”字符串作为开头； - - -server_names - -
Referer
请求头包含某个虚拟主机名； - - -任意字符串 - -定义一个服务器名和可选的URI前缀。服务器名允许在开头或结尾使用“*”符号。 -当nginx检查时，
Referer
请求头里的服务器端口将被忽略。 - - -正则表达式 - -必须以“~”符号作为开头。 -需要注意的是表达式会从“http://”或者“https://”之后的文本开始匹配。 - - - - - - -实例: - -valid_referers none blocked server_names - *.example.com example.* www.example.org/galleries/ - ~\.google\.; - - - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_rewrite_module.xml b/xml/cn/docs/http/ngx_http_rewrite_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_rewrite_module.xml +++ /dev/null @@ -1,374 +0,0 @@ - - - - - - - - -
- - -ngx_http_rewrite_module模块允许正则替换URI，返回页面重定向，和按条件选择配置。 - - - -ngx_http_rewrite_module模块指令按以下顺序处理： - - - -处理在级别中定义的模块指令； - - - -为请求查找location； - - - -处理在选中的中定义的模块指令。如果指令改变了URI，按新的URI查找location。这个循环至多重复10次，之后nginx返回错误。 - - - - - -
- - -
- - - - -server -location -if - - -停止处理当前这一轮的ngx_http_rewrite_module指令集。 - - - -举例： - -if ($slow) { - limit_rate 10k; - break; -} - - - - - - - -(condition) - -server -location - - -计算指定的condition的值。如果为真，执行定义在大括号中的rewrite模块指令，并将if指令中的配置指定给请求。if指令会从上一层配置中继承配置。 - - - -条件可以是下列任意一种： - - - -变量名；如果变量值为空或者是以“0”开始的字符串，则条件为假； - - - -使用“=”和“!=”运算符比较变量和字符串； - - - -使用“~”（大小写敏感）和“~*”（大小写不敏感）运算符匹配变量和正则表达式。正则表达式可以包含匹配组，匹配结果后续可以使用变量$1..$9引用。如果正则表达式中包含字符“}”或者“;”，整个表达式应该被包含在单引号或双引号的引用中。 - - - -使用“-f”和“!-f”运算符检查文件是否存在； - - - -使用“-d”和“!-d”运算符检查目录是否存在； - - - -使用“-e”和“!-e”运算符检查文件、目录或符号链接是否存在； - - - -使用“-x”和“!-x”运算符检查可执行文件； - - - - - - -举例： - -if ($http_user_agent ~ MSIE) { - rewrite ^(.*)$ /msie/$1 break; -} - -if ($http_cookie ~* "id=([^;]+)(?:;|$)") { - set $id $1; -} - -if ($request_method = POST) { - return 405; -} - -if ($slow) { - limit_rate 10k; -} - -if ($invalid_referer) { - return 403; -} - - -内嵌变量$invalid_referer的值是通过指令设置的。 - - - - - - - -code [text] -code URL -URL - -server -location -if - - -停止处理并返回指定code给客户端。返回非标准的状态码444可以直接关闭连接而不返回响应头。 - - - -从0.8.42版开始，可以在指令中指定重定向的URL（状态码为301、302、303和307），或者指定响应体文本（状态码为其它值）。响应体文本或重定向URL中可以包含变量。作为一种特殊情况，重定向URL可以简化为当前server的本地URI，那么完整的重定向URL将按照请求协议（$scheme）、指令和指令的配置进行补全。 - - - -另外，状态码为302的临时重定向使用的URL可以作为指令的唯一参数。该参数应该以“http://”、“https://”或者“https://”开始。URL中可以包含变量。 - - - - -0.7.51版本以前只能返回下面状态码： -204、400、402 — 406、408、410、411、413、416 和 500 — 504。 - - - -直到1.1.16和1.0.13版，状态码307才被认为是一种重定向。 - - - - - - - - - regex - replacement - [flag] - -server -location -if - - -如果指定的正则表达式能匹配URI，此URI将被replacement参数定义的字符串改写。rewrite指令按其在配置文件中出现的顺序执行。flag可以终止后续指令的执行。如果replacement的字符串以“http://”或“https://”开头，nginx将结束执行过程，并返回给客户端一个重定向。 - - - -可选的flag参数可以是其中之一： - - -last - -停止执行当前这一轮的ngx_http_rewrite_module指令集，然后查找匹配改变后URI的新location； - - -break - -停止执行当前这一轮的ngx_http_rewrite_module指令集； - - -redirect - -在replacement字符串未以“http://”或“https://”开头时，使用返回状态码为302的临时重定向； - - -permanent - -返回状态码为301的永久重定向。 - - - -完整的重定向URL将按照请求协议（$scheme）、指令和指令的配置进行补全。 - - - -举例： - -server { - ... - rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last; - rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra last; - return 403; - ... -} - - - - -但是当上述指令写在“/download/”的location中时，应使用标志break代替last，否则nginx会重复10轮循环，然后返回错误500： - -location /download/ { - rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break; - rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra break; - return 403; -} - - - - -如果replacement字符串包括新的请求参数，以往的请求参数会添加到新参数后面。如果不希望这样，在replacement字符串末尾加一个问号“？”，就可以避免，比如： - -rewrite ^/users/(.*)$ /show?user=$1? last; - - - - -如果正则表达式中包含字符“}”或者“;”，整个表达式应该被包含在单引号或双引号的引用中。 - - - - - - -on | off -off -http -server -location -if - - -开启或者关闭将ngx_http_rewrite_module模块指令的处理日志以notice级别记录到错误日志中。 - - - - - - -variable value - -server -location -if - - -为指定变量variable设置变量值value。value可以包含文本、变量或者它们的组合。 - - - - - - -on | off -on -http -server -location -if - - -控制是否记录变量未初始化的警告到日志。 - - - - -
- - -
- - -ngx_http_rewrite_module模块的指令在解析配置阶段被编译成nginx内部指令。这些内部指令在处理请求时被解释执行。而解释器是一个简单的堆栈机器。 - - - -比如，下面指令 - -location /download/ { - if ($forbidden) { - return 403; - } - - if ($slow) { - limit_rate 10k; - } - - rewrite ^/(download/.*)/media/(.*)\..*$ /$1/mp3/$2.mp3 break; -} - -将被翻译成下面这些指令： - -variable $forbidden -check against zero - return 403 - end of code -variable $slow -check against zero -match of regular expression -copy "/" -copy $1 -copy "/mp3/" -copy $2 -copy ".mp3" -end of regular expression -end of code - - - - -请注意没有对应上面的指令的内部指令，因为这个指令与ngx_http_rewrite_module模块无关。nginx会为这个块单独创建一个配置，包含limit_rate等于10k。如果条件为真，nginx将把这个配置指派给请求。 - - - -指令 - -rewrite ^/(download/.*)/media/(.*)\..*$ /$1/mp3/$2.mp3 break; - -可以通过将正则表达式中的第一个斜线“/”放入圆括号，来实现节约一个内部指令： - -rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 break; - -对应的内部指令将会是这样： - -match of regular expression -copy $1 -copy "/mp3/" -copy $2 -copy ".mp3" -end of regular expression -end of code - - - -
- - diff --git a/xml/cn/docs/http/ngx_http_upstream_module.xml b/xml/cn/docs/http/ngx_http_upstream_module.xml deleted file mode 100644 --- a/xml/cn/docs/http/ngx_http_upstream_module.xml +++ /dev/null @@ -1,366 +0,0 @@ - - - - - - - - -
- - -ngx_http_upstream_module模块 -允许定义一组服务器。它们可以在指令、 -和 -中被引用到。 - - -
- - -
- - - -upstream backend { - server backend1.example.com weight=5; - server backend2.example.com:8080; - server unix:/tmp/backend3; - - server backup1.example.com:8080 backup; - server backup2.example.com:8080 backup; -} - -server { - location / { - proxy_pass http://backend; - } -} - - - -
- - -
- - -name - -http - - -定义一组服务器。 -这些服务器可以监听不同的端口。 -而且，监听在TCP和UNIX域套接字的服务器可以混用。 - - - -例子： - -upstream backend { - server backend1.example.com weight=5; - server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; - server unix:/tmp/backend3; -} - - - - -默认情况下，nginx按加权轮转的方式将请求分发到各服务器。 -在上面的例子中，每7个请求会通过以下方式分发： -5个请求分到backend1.example.com， -一个请求分到第二个服务器，一个请求分到第三个服务器。 -与服务器通信的时候，如果出现错误，请求会被传给下一个服务器，直到所有可用的服务器都被尝试过。 -如果所有服务器都返回失败，客户端将会得到最后通信的那个服务器的（失败）响应结果。 - - - - - - -address [parameters] - -upstream - - -定义服务器的地址address和其他参数parameters。 -地址可以是域名或者IP地址，端口是可选的，或者是指定“unix:”前缀的UNIX域套接字的路径。如果没有指定端口，就使用80端口。 -如果一个域名解析到多个IP，本质上是定义了多个server。 - - - -你可以定义下面的参数： - - -weight=number - -设定服务器的权重，默认是1。 - - -max_fails=number - -设定Nginx与服务器通信的尝试失败的次数。在fail_timeout参数定义的时间段内，如果失败的次数达到此值，Nginx就认为服务器不可用。在下一个fail_timeout时间段，服务器不会再被尝试。 -失败的尝试次数默认是1。设为0就会停止统计尝试次数，认为服务器是一直可用的。 -你可以通过指令、 -和 -来配置什么是失败的尝试。 -默认配置时，http_404状态不被认为是失败的尝试。 - - -fail_timeout=time - -设定 - - - -统计失败尝试次数的时间段。在这段时间中，服务器失败次数达到指定的尝试次数，服务器就被认为不可用。 - - - -服务器被认为不可用的时间段。 - - - -默认情况下，该超时时间是10秒。 - - -backup - -标记为备用服务器。当主服务器不可用以后，请求会被传给这些服务器。 - - -down - -标记服务器永久不可用，可以跟指令一起使用。 - - - - - - -Example: - -upstream backend { - server backend1.example.com weight=5; - server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; - server unix:/tmp/backend3; - - server backup1.example.com:8080 backup; -} - - - - - - - - - -upstream - - -指定服务器组的负载均衡方法，请求基于客户端的IP地址在服务器间进行分发。 -IPv4地址的前三个字节或者IPv6的整个地址，会被用来作为一个散列key。 -这种方法可以确保从同一个客户端过来的请求，会被传给同一台服务器。除了当服务器被认为不可用的时候，这些客户端的请求会被传给其他服务器，而且很有可能也是同一台服务器。 - -从1.3.2和1.2.2版本开始支持IPv6地址。 - - - - -如果其中一个服务器想暂时移除，应该加上down参数。这样可以保留当前客户端IP地址散列分布。 - - - -例子： - -upstream backend { - ip_hash; - - server backend1.example.com; - server backend2.example.com; - server backend3.example.com down; - server backend4.example.com; -} - - - - - -从1.3.1和1.2.2版本开始，ip_hash的负载均衡方法才支持设置服务器权重值。 - - - - - - - -connections - -upstream -1.1.4 - - -激活对上游服务器的连接进行缓存。 - - - -connections参数设置每个worker进程与后端服务器保持连接的最大数量。这些保持的连接会被放入缓存。 -如果连接数大于这个值时，最久未使用的连接会被关闭。 - -需要注意的是，keepalive指令不会限制Nginx进程与上游服务器的连接总数。 -新的连接总会按需被创建。 -connections参数应该稍微设低一点，以便上游服务器也能处理额外新进来的连接。 - - - - -配置memcached上游服务器连接keepalive的例子： - -upstream memcached_backend { - server 127.0.0.1:11211; - server 10.0.0.2:11211; - - keepalive 32; -} - -server { - ... - - location /memcached/ { - set $memcached_key $uri; - memcached_pass memcached_backend; - } - -} - - - - -对于HTTP代理，指令应该设置为“1.1”，同时
Connection
头的值也应被清空。 - -upstream http_backend { - server 127.0.0.1:8080; - - keepalive 16; -} - -server { - ... - - location /http/ { - proxy_pass http://http_backend; - proxy_http_version 1.1; - proxy_set_header Connection ""; - ... - } -} - - - - - -另外一种选择是，HTTP/1.0协议的持久连接也可以通过发送
Connection: Keep-Alive
头来实现。不过不建议这样用。 - - - - -对于FastCGI的服务器，需要设置 - -指令来让连接keepalive工作： - -upstream fastcgi_backend { - server 127.0.0.1:9000; - - keepalive 8; -} - -server { - ... - - location /fastcgi/ { - fastcgi_pass fastcgi_backend; - fastcgi_keep_conn on; - ... - } -} - - - - - -当使用的负载均衡方法不是默认的轮转法时，必须在keepalive 指令之前配置。 - - - -针对SCGI和uwsgi协议，还没有实现其keepalive连接的打算。 - - - - - - - - - -upstream -1.3.1 -1.2.2 - - -指定服务器组的负载均衡方法，根据其权重值，将请求发送到活跃连接数最少的那台服务器。 -如果这样的服务器有多台，那就采取有权重的轮转法进行尝试。 - - - - -
- - -
- - -ngx_http_upstream_module模块支持以下嵌入变量： - - - -$upstream_addr - -保存服务器的IP地址和端口或者是UNIX域套接字的路径。 -在请求处理过程中，如果有多台服务器被尝试了，它们的地址会被拼接起来，以逗号隔开，比如： -“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock”。 -如果在服务器之间通过
X-Accel-Redirect
头或者有内部跳转，那么这些服务器组之间会以冒号隔开，比如：“192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80”。 - - -$upstream_response_time - -以毫秒的精度保留服务器的响应时间，（输出）单位是秒。 -出现多个响应时，也是以逗号和冒号隔开。 - - -$upstream_status - -保存服务器的响应代码。 -出现多个响应时，也是以逗号和冒号隔开。 - - -$upstream_http_... - -保存服务器的响应头的值。比如
Server
响应头的值可以通过$upstream_http_server变量来获取。 -需要注意的是只有最后一个响应的头会被保留下来。 - - - - - -
- - diff --git a/xml/cn/docs/http/request_processing.xml b/xml/cn/docs/http/request_processing.xml deleted file mode 100644 --- a/xml/cn/docs/http/request_processing.xml +++ /dev/null @@ -1,216 +0,0 @@ - - - - -
- - -
- - -Nginx首先选定由哪一个虚拟主机来处理请求。让我们从一个简单的配置（其中全部3个虚拟主机都在端口*：80上监听）开始： - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name example.net www.example.net; - ... -} - -server { - listen 80; - server_name example.com www.example.com; - ... -} - - - - -在这个配置中，nginx仅仅检查请求的
Host
头以决定该请求应由哪个虚拟主机来处理。如果Host头没有匹配任意一个虚拟主机，或者请求中根本没有包含Host头，那nginx会将请求分发到定义在此端口上的默认虚拟主机。在以上配置中，第一个被列出的虚拟主机即nginx的默认虚拟主机——这是nginx的默认行为。而且，可以显式地设置某个主机为默认虚拟主机，即在"listen"指令中设置"default_server"参数： - - -server { - listen 80 default_server; - server_name example.net www.example.net; - ... -} - - - -"default_server"参数从0.8.21版开始可用。在之前的版本中，应该使用"default"参数代替。 - - -请注意"default_server"是监听端口的属性，而不是主机名的属性。后面会对此有更多介绍。 - - -
- - -
- - -如果不允许请求中缺少
Host
头，可以定义如下主机，丢弃这些请求： - - -server { - listen 80; - server_name ""; - return 444; -} - - -在这里，我们设置主机名为空字符串以匹配未定义
Host
头的请求，而且返回了一个nginx特有的，非http标准的返回码444，它可以用来关闭连接。 -从0.8.48版本开始，这已成为主机名的默认设置，所以可以省略server_name ""。而之前的版本使用机器的hostname作为主机名的默认值。 - - -
- - -
- - -下面让我们来看一个复杂点的配置，在这个配置里，有几个虚拟主机在不同的地址上监听： - - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80; - server_name example.com www.example.com; - ... -} - - -这个配置中，nginx首先测试请求的IP地址和端口是否匹配某个配置块中的指令配置。接着nginx继续测试请求的Host头是否匹配这个块中的某个的值。如果主机名没有找到，nginx将把这个请求交给默认虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问www.example.com的请求将被监听192.168.1.1:80端口的默认虚拟主机处理，本例中就是第一个服务器，因为这个端口上没有定义名为www.example.com的虚拟主机。 - - - -默认服务器是监听端口的属性，所以不同的监听端口可以设置不同的默认服务器： - - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80 default_server; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80 default_server; - server_name example.com www.example.com; - ... -} - - - -
- - -
- - -现在我们来看在一个典型的，简单的PHP站点中，nginx怎样为一个请求选择location来处理： - - -server { - listen 80; - server_name example.org www.example.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; - } -} - - - - -首先，nginx使用前缀匹配找出最准确的location，这一步nginx会忽略location在配置文件出现的顺序。上面的配置中，唯一的前缀匹配location是"/"，而且因为它可以匹配任意的请求，所以被作为最后一个选择。接着，nginx继续按照配置中的顺序依次匹配正则表达式的location，匹配到第一个正则表达式后停止搜索。匹配到的location将被使用。如果没有匹配到正则表达式的location，则使用刚刚找到的最准确的前缀匹配的location。 - - - -请注意所有location匹配测试只使用请求的URI部分，而不使用参数部分。这是因为写参数的方法很多，比如： - - -/index.php?user=john&page=1 -/index.php?page=1&user=john - - -除此以外，任何人在请求串中都可以随意添加字符串： - - -/index.php?page=1&something+else&user=john - - - - -现在让我们来看使用上面的配置，请求是怎样被处理的： - - - - -请求"/logo.gif"首先匹配上location "/"，然后匹配上正则表达式"\.(gif|jpg|png)$"。因此，它将被后者处理。根据"root /data/www"指令，nginx将请求映射到文件/data/www/logo.gif"，并发送这个文件到客户端。 - - - -请求"/index.php"首先也匹配上location "/"，然后匹配上正则表达式"\.(php)$"。 因此，它将被后者处理，进而被发送到监听在localhost:9000的FastCGI服务器。指令将FastCGI的参数SCRIPT_FILENAME的值设置为"/data/www/index.php"，接着FastCGI服务器执行这个文件。变量$document_root等于指令设置的值，变量$fastcgi_script_name的值是请求的uri，"/index.php"。 - - - -请求"/about.html"仅能匹配上location "/"，因此，它将使用此location进行处理。根据"root /data/www"指令，nginx将请求映射到文件"/data/www/about.html"，并发送这个文件到客户端。 - - - -请求"/"的处理更为复杂。它仅能匹配上location "/"，因此，它将使用此location进行处理。然后，指令使用它的参数和"root /data/www"指令所组成的文件路径来检测对应的文件是否存在。如果文件/data/www/index.html不存在，而/data/www/index.php存在，此指令将执行一次内部重定向到"/index.php"，接着nginx将重新寻找匹配"/index.php"的location，就好像这次请求是从客户端发过来一样。正如我们之前看到的那样，这个重定向的请求最终交给FastCGI服务器来处理。 - - - - - -
- -
diff --git a/xml/cn/docs/http/server_names.xml b/xml/cn/docs/http/server_names.xml deleted file mode 100644 --- a/xml/cn/docs/http/server_names.xml +++ /dev/null @@ -1,378 +0,0 @@ - - - - -
- - -
- - - -虚拟主机名使用指令定义，用于决定由某台虚拟主机来处理请求。具体请参考《nginx如何处理一个请求》。虚拟主机名可以使用确切的名字，通配符，或者是正则表达式来定义： - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name *.example.org; - ... -} - -server { - listen 80; - server_name mail.*; - ... -} - -server { - listen 80; - server_name ~^(?<user>.+)\.example\.net$; - ... -} - - -nginx以名字查找虚拟主机时，如果名字可以匹配多于一个主机名定义，比如同时匹配了通配符的名字和正则表达式的名字，那么nginx按照下面的优先级别进行查找，并选中第一个匹配的虚拟主机： - - - - -确切的名字； - - - -最长的以星号起始的通配符名字：*.example.org； - - - -最长的以星号结束的通配符名字：mail.*； - - - -第一个匹配的正则表达式名字（按在配置文件中出现的顺序）。 - - - - - -
- - -
- - -通配符名字只可以在名字的起始处或结尾处包含一个星号，并且星号与其他字符之间用点分隔。所以，“www.*.example.org”和“w*.example.org”都是非法的。不过，上面的两个名字可以使用正则表达式描述，即“~^www\..+\.example\.org$”和“~^w.*\.example\.org$”。星号可以匹配名字的多个节（各节都是以点号分隔的）。“*.example.org”不仅匹配www.example.org，也匹配www.sub.example.org。 - - - -有一种形如“.example.org”的特殊通配符，它可以既匹配确切的名字“example.org”，又可以匹配一般的通配符名字“*.example.org”。 - - -
- - -
- - -nginx使用的正则表达式兼容PCRE。为了使用正则表达式，虚拟主机名必须以波浪线“~”起始： - - -server_name ~^www\d+\.example\.net$; - - -否则该名字会被认为是个确切的名字，如果表达式含星号，则会被认为是个通配符名字（而且很可能是一个非法的通配符名字）。不要忘记设置“^”和“$”锚点，语法上它们不是必须的，但是逻辑上是的。同时需要注意的是，域名中的点“.”需要用反斜线“\”转义。含有“{”和“}”的正则表达式需要被引用，如： - - -server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; - - -否则nginx就不能启动，错误提示是： - - -directive "server_name" is not terminated by ";" in ... - - -命名的正则表达式捕获组在后面可以作为变量使用： - - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - - -PCRE使用下面语法支持命名捕获组： - - - - - - - - - - - - - - - - - - -
?<name>从PCRE-7.0开始支持，兼容Perl 5.10语法
?'name'从PCRE-7.0开始支持，兼容Perl 5.10语法
?P<name>从PCRE-4.0开始支持，兼容Python语法
- -如果nginx不能启动，并显示错误信息： - - -pcre_compile() failed: unrecognized character after (?< in ... - - -说明PCRE版本太旧，应该尝试使用?P<name>。捕获组也可以以数字方式引用： - - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - - -不过，这种用法只限于简单的情况（比如上面的例子），因为数字引用很容易被覆盖。 - - - -
- - -
- - -有一些主机名会被特别对待。 - - - -如果需要用一个非默认的虚拟主机处理请求头中不含
Host
字段的请求，需要指定一个空名字： - - -server { - listen 80; - server_name example.org www.example.org ""; - ... -} - - - - -如果块中没有定义，nginx使用空名字作为虚拟主机名。 - -nginx 0.8.48版本以下（含）在同样的情况下会使用机器名作为虚拟主机名。 - - - - -如果以“$hostname”（nginx 0.9.4及以上版本）定义虚拟主机名，机器名将被使用。 - - - -如果使用IP地址而不是主机名来请求服务器，那么请求头的
Host
字段包含的将是IP地址。可以将IP地址作为虚拟主机名来处理这种请求： - - -server { - listen 80; - server_name nginx.org - www.nginx.org - "" - 192.168.1.1 - ; - ... -} - - - - -在匹配所有的服务器的例子中，可以见到一个奇怪的名字“_”： - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -这没什么特别的，它只不过是成千上万的与真实的名字绝无冲突的非法域名中的一个而已。当然，也可以使用“--”和“!@#”等等。 - - - -nginx直到0.6.25版本还支持一个特殊的名字“*”，这个名字一直被错误地理解成是一个匹配所有的名字。但它从来没有像匹配所有的名字，或者通配符那样工作过，而是用来支持一种功能，此功能现在已经改由指令提供支持了。所以，现在这个特殊的名字“*”已经过时了，应该使用指令取代它。需要注意的是，使用指令无法描述匹配所有的名字或者默认服务器。这是指令的属性，而不是指令的属性。具体请参考《nginx如何处理一个请求》。可以定义两个服务器都监听*:80和*:8080端口，然后指定一个作为端口*:8080的默认服务器，另一个作为端口*:80的默认服务器： - - -server { - listen 80; - listen 8080 default_server; - server_name example.net; - ... -} - -server { - listen 80 default_server; - listen 8080; - server_name example.org; - ... -} - - - - -
- - -
- - -确切名字和通配符名字存储在哈希表中。哈希表和监听端口关联。哈希表的尺寸在配置阶段进行了优化，可以以最小的CPU缓存命中失败来找到名字。设置哈希表的细节参见这篇文档 - - - -nginx首先搜索确切名字的哈希表，如果没有找到，搜索以星号起始的通配符名字的哈希表，如果还是没有找到，继续搜索以星号结束的通配符名字的哈希表。 - - - -因为名字是按照域名的节来搜索的，所以搜索通配符名字的哈希表比搜索确切名字的哈希表慢。注意特殊的通配符名字“.example.org”存储在通配符名字的哈希表中，而不在确切名字的哈希表中。 - - - -正则表达式是一个一个串行的测试，所以是最慢的，而且不可扩展。 - - - -鉴于以上原因，请尽可能使用确切的名字。举个例子，如果使用example.org和www.example.org来访问服务器是最频繁的，那么将它们明确的定义出来就更为有效： - - -server { - listen 80; - server_name example.org www.example.org *.example.org; - ... -} - - -下面这种方法相比更简单，但是效率也更低： - - -server { - listen 80; - server_name .example.org; - ... -} - - - - -如果定义了大量名字，或者定义了非常长的名字，那可能需要在http配置块中使用和指令进行调整。的默认值可能是32，或者是64，或者是其他值，取决于CPU的缓存行的长度。如果这个值是32，那么定义“too.long.server.name.example.org”作为虚拟主机名就会失败，而nginx显示下面错误信息： - -could not build the server_names_hash, -you should increase server_names_hash_bucket_size: 32 - - -出现了这种情况，那就需要将指令的值扩大一倍： - - -http { - server_names_hash_bucket_size 64; - ... - - -如果定义了大量名字，得到了另外一个错误： - - -could not build the server_names_hash, -you should increase either server_names_hash_max_size: 512 -or server_names_hash_bucket_size: 32 - - -那么应该先尝试设置的值差不多等于名字列表的名字总量。如果还不能解决问题，或者服务器启动非常缓慢，再尝试提高的值。 - - - -如果只为一个监听端口配置了唯一的主机，那么nginx就完全不会测试虚拟主机名了（也不会为监听端口建立哈希表）。不过，有一个例外，如果定义的虚拟主机名是一个含有捕获组的正则表达式，这时nginx就不得不执行这个表达式以得到捕获组。 - - -
- - -
- - - - - -从0.9.4版本开始，支持特殊的虚拟主机名“$hostname”。 - - - -从0.8.48版本开始，默认的虚拟主机名是空名字“”。 - - - -从0.8.25版本开始，支持虚拟主机名中使用命名的正则表达式捕获组。 - - - -从0.7.40版本开始，支持虚拟主机名中使用正则表达式的捕获组。 - - - -从0.7.12版本开始，支持空名字“”。 - - - -从0.6.25版本开始，通配符和正则表达式名字可以作为第一个虚拟主机名。 - - - -从0.6.7版本开始，支持正则表达式的虚拟主机名。 - - - -从0.6.0版本开始，支持形如example.*的通配符名字。 - - - -从0.3.18版本开始，支持形如.example.org的特殊通配符名字。 - - - -从0.1.13版本开始，支持形如*.example.org的通配符名字。 - - - - - -
- -
diff --git a/xml/cn/docs/index.xml b/xml/cn/docs/index.xml deleted file mode 100644 --- a/xml/cn/docs/index.xml +++ /dev/null @@ -1,180 +0,0 @@ - - - - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - -
- - -
- - - - - - -ngx_http_access_module - - - - -ngx_http_addition_module - - - - -ngx_http_auth_basic_module - - - - -ngx_http_autoindex_module - - - - -ngx_http_browser_module - - - - -ngx_http_core_module - - - - -ngx_http_empty_gif_module - - - - -ngx_http_flv_module - - - - -ngx_http_geo_module - - - - -ngx_http_geoip_module - - - - -ngx_http_gzip_static_module - - - - -ngx_http_image_filter_module - - - - -ngx_http_index_module - - - - -ngx_http_limit_conn_module - - - - -ngx_http_limit_req_module - - - - -ngx_http_log_module - - - - -ngx_http_map_module - - - - -ngx_http_proxy_module - - - - -ngx_http_referer_module - - - - -ngx_http_rewrite_module - - - - -ngx_http_upstream_module - - - - - -
- -
diff --git a/xml/cn/docs/syntax.xml b/xml/cn/docs/syntax.xml deleted file mode 100644 --- a/xml/cn/docs/syntax.xml +++ /dev/null @@ -1,42 +0,0 @@ - - - - -
- -
- - -容量可以用千字节(k，K)和兆字节(m，M)来描述，比如“8k”，“1m”。 -如果没有指定单位，容量以字节为单位。 - - - -时间可以用分钟、小时、天等来描述： - - - - - - - - -
s秒
m分钟
h小时
d天
w周
M月，30天
y年，365天
- - - -比如，“1h 30m”，“1y 6M”。 -另外，在一些指令中，描述时间可以精确到毫秒精度(ms)。 -如果没有指定单位，时间以秒为单位。 - - -
- -
diff --git a/xml/cn/docs/sys_errlist.xml b/xml/cn/docs/sys_errlist.xml deleted file mode 100644 --- a/xml/cn/docs/sys_errlist.xml +++ /dev/null @@ -1,31 +0,0 @@ - - - - -
- - -
- - -在Linux环境下编译nginx 0.7.66、0.8.35或更高版本时，会出现以下警告： - - -warning: `sys_errlist' is deprecated; - use `strerror' or `strerror_r' instead -warning: `sys_nerr' is deprecated; - use `strerror' or `strerror_r' instead - - -这属于正常情况：nginx必须在信号处理函数中使用过时的sys_errlist[]和sys_nerr，因为strerror()和strerror_r()是非异步信号安全的。 - - -
- -
diff --git a/xml/cn/docs/welcome_nginx_facebook.xml b/xml/cn/docs/welcome_nginx_facebook.xml deleted file mode 100644 --- a/xml/cn/docs/welcome_nginx_facebook.xml +++ /dev/null @@ -1,120 +0,0 @@ - - - - -
- -
- - -问： -我尝试打开Facebook，Yahoo!，Yandex，Tumblr，Google，或者其他一些知名网站时，但是得到的都是空白页，页面上有一条与nginx相关的信息：“Welcome to nginx!”或者是“404 Not Found / nginx”。 - - - - -我怀疑出了什么问题，而且有可能有恶意的企图要把我引导到流氓页面去（为了黑掉我的电脑，钓鱼等等）。为什么？nginx跟我想连上Facebook（Yahoo!，Google等等）有什么关系？ - - - -  - - - -答： -第一，你看到的“Welcome to nginx!”不是我们的网站。nginx是我们开发和分发的一个免费的开源web服务器软件。“Welcome to nginx!”的页面只是任何一个运行nginx服务器的网站都会返回的诊断响应。目前，nginx是世界上第二流行的开源web服务器，它被70,000,000网站（因特网的10%）所使用。这些网站中绝大多数都是合法的，但也有一些不是。我们的软件是本着让因特网上具备高性能和高扩展性的好意而创造的，它遵循流行的开源许可，本质上与任何威胁和恶意行为都没有任何关系————nginx不是恶意软件，它也不在你的电脑上。但是某些恶意软件确实会篡改你的电脑或者路由器，把你引导到某个欺诈的因特网服务器上。 - - - -(免责声明: 对于下列行为造成的任何负面影响和效果，nginx不承担任何责任。按下面建议进行操作时，您需要自行承担风险。尤其是您对您的操作系统和/或因特网应用不是很有经验时，这点非常重要。对任何直接的，间接的，偶然的，特殊的，典型的，或者继发的损害，包括但不限于使用、数据、收益方面的损失，或者营业中断，nginx不负有任何责任）。 - - - - - -检查你的TCP/IP设置，查看DNS配置是否合法（请咨询ISP或IT支持人员） - - - -使用Google -Public DNS, 尝试修复这个问题。Google Public DNS的描述是：“Google Public DNS是一款免费的全球域名系统（DNS）解析服务，您可以使用它替代您当前的DNS供应服务。[..]使用Google Public DNS，你可以：加速您的浏览体验。提升你的安全性。” - - - -清除您的DNS解析缓存。在微软Windos XP上，运行“开始” > “运行”，然后输入下面指令：“ipconfig /flushdns”。在微软Vista, Windows 7和Windows 8上，点击“开始”图标，找到“所有应用” > “附件” > “命令提示符”，右击，选择“以管理员身份运行”，再输入“ipconfig /flushdns”，敲回车键。 - - - -点击浏览器上的“刷新”按钮。清空浏览器的数据（缓存，cookie等等）。比如，使用Chrome浏览器，找到并点击“清除浏览数据”（设置 > 显示高级设置）。使用IE浏览器，找到“工具” > “Interner选项” > “常规”）。注意：您在这里可能删除您保存的密码信心，所以请仔细操作并检查您正在进行的究竟是何种操作。 - - - -检查“hosts”文件中是否不包含除“127.0.0.1 localhost”以外的其他项；如果不是，那么这些项中是否有您要访问的网站。“hosts”文件位于C:\WINDOWS\system32\drivers\etc文件夹下。通常文件中应该只有一项“127.0.0.1 localhost”。“hosts”文件可以使用记事本查看和编辑。 - - - -检查安装到您的浏览器中的插件和扩展。重新安装您的浏览器或者如果可能的话，使用其他浏览器替代。 - - - - - -当你尝试访问一些知名网站的时候，得到的不是熟悉的页面反而是“Welcome to nginx!”的时候，你的操作系统设置，家用路由器设置，或者浏览器设置一定有问题。如果你的电脑是干净且安全的，就不应该出现这种情况。 - - - -如果将DNS服务器换成Google Public DNS，刷新DNS解析缓存，修复您的浏览器配置，或者清理“hosts”文件（适当的）确实解决了问题，那么您的电脑上或者周边网络中可能存在着恶意软件。使用您偏好的杀毒软件和恶意软件清除工具找出并清除它们。 - - - -其他可能有用的文章： - - - -DCWG.org: - - - -如何发现您的电脑是否已经被DNS Changer侵犯和感染？ - - - - -如何清理或修复恶意软件DNS Changer - - - -Microsoft: - - - -恶意软件删除工具 - - - - -如何将主机文件重置回默认值？ - - - - -如何重置 Internet 协议 (TCP/IP) - - - -Tech-Recipes: - - - -在Vista，Windows 7和Windows 8系统中刷新，清除，重置DNS缓存 - - -
- -
diff --git a/xml/cn/docs/windows.xml b/xml/cn/docs/windows.xml deleted file mode 100644 --- a/xml/cn/docs/windows.xml +++ /dev/null @@ -1,127 +0,0 @@ - - - - -
- - -
- - -nginx的Windows版本使用原生Win32 API（非Cygwin模拟层）。当前nginx/Windows只使用select作为通知方法，所以不要期待它有很高的性能和扩展性。鉴于这点和一些已知问题，nginx/Windows目前还处于beta阶段。nginx/Windows和Unix版本相比，功能几乎已经齐全，除了XSLT过滤器、图像过滤器、GeoIP模块和嵌入Perl语言支持以外。 - - - -安装nginx/Windows，需要下载最新的开发版本，因为开发分支上包含了所有已知的问题修复，尤其是针对Windows版本的问题修复。解压缩下载得到的zip文件，进入nginx-目录，运行nginx。下面给出一个在C盘根目录下安装的例子： - - -cd c:\ -unzip nginx-.zip -cd nginx- -start nginx - - -可以在命令行运行tasklist命令来查看nginx进程： - - -C:\nginx->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 - - -其中一个是主进程，另一个是工作进程。如果nginx没有启动，请查看logs\error.log文件以寻找失败原因。如果日志文件不存在，那失败原因会记录在Windows事件日志中。如果某次请求没有展示预想的页面，而是展示了错误页面，也请查看logs\error.log文件。 - - - -nginx/Windows使用工作目录作为前缀将配置文件中设置的相对目录补齐。就上面安装的例子而言，工作目录应该是C:\nginx-\（工作目录基本上与运行文件所在的目录相同）。配置文件中的目录请使用“/”，而不是“\”做目录分隔： - - -access_log logs/site.log; -root C:/web/html; - - - - -nginx/Windows作为标准控制台应用运行，而不是系统服务。可以用下面的命令控制： - - - - - - - - - - - - - - - - - - - - - - - -
nginx -s stop快速退出
nginx -s quit优雅退出
nginx -s reload -更换配置，启动新的工作进程，优雅的关闭以往的工作进程 -
nginx -s reopen重新打开日志文件
- - -
- -
- - - - -虽然可以启动若干工作进程运行，实际上只有一个进程在处理请求所有请求。 - - - -一个工作进程只能处理不超过1024个并发连接。 - - - -缓存和其他需要共享内存支持的模块在Windows Vista及后续版本的操作系统中无法工作，因为在这些操作系统中，地址空间的布局是随机的。 - - - - -
- -
- - - - -作为系统服务运行。 - - - -使用“I/O完成端口”作为事件模型。 - - - -使用单工作进程多线程的模型。 - - - - -
- -
diff --git a/xml/cn/index.xml b/xml/cn/index.xml deleted file mode 100644 --- a/xml/cn/index.xml +++ /dev/null @@ -1,272 +0,0 @@ - - - - -
- - -
- - -nginx [engine x]是Igor Sysoev编写的一个HTTP和反向代理服务器，另外它也可以作为邮件代理服务器。 -它已经在众多流量很大的俄罗斯网站上使用了很长时间，这些网站包括Yandex、Mail.Ru、VKontakte，以及Rambler。据Netcraft统计，在2012年8月份，世界上最繁忙的网站中有11.48%使用Nginx作为其服务器或者代理服务器。部分成功案例请见： -Netflix， -Wordpress.com， -FastMail.FM。 - - - -Nginx的源码使用的许可为两条款类BSD协议。 - - -
- - -
- - - - - -处理静态文件，索引文件以及自动索引；打开文件描述符缓存； - - - -使用缓存加速反向代理；简单负载均衡以及容错； - - - -远程FastCGI，uwsgi，SCGI，和memcached服务的缓存加速支持；简单的负载均衡以及容错； - - - -模块化的架构。过滤器包括gzip压缩、ranges支持、chunked响应、XSLT，SSI以及图像缩放。在SSI 过滤器中，一个包含多个SSI的页面，如果经由FastCGI或反向代理处理，可被并行处理； - - - -支持SSL，TLS SNI。 - - - - - -
- - -
- - - - - -基于名字和IP的虚拟主机； - - - -Keep-alive和pipelined连接支持； - - - -灵活的配置； - - - -重新加载配置以及在线升级时，不需要中断正在处理的请求； - - - -自定义访问日志格式，带缓存的日志写操作以及快速日志轮转； - - - -3xx-5xx错误代码重定向； - - - -重写（rewrite）模块：使用正则表达式改变URI； - - - -根据客户端地址执行不同的功能； - - - -基于客户端IP地址和HTTP基本认证机制的访问控制； - - - -支持验证HTTP referer； - - - -支持PUT、DELETE、MKCOL、COPY以及MOVE方法； - - - -支持FLV流和MP4流； - - - -速度限制； - - - -来自同一地址的同时连接数或请求数限制； - - - -嵌入Perl语言。 - - - - - -
- - -
- - - - - -使用外部HTTP认证服务器重定向用户到IMAP/POP3后端； - - - -使用外部HTTP认证服务器认证用户后重定向连接到内部SMTP后端； - - - -支持的认证方式： - - - - -POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -SMTP: AUTH LOGIN/PLAIN/CRAM-MD5; - - - - - - -SSL支持； - - - -STARTTLS和STLS支持。 - - - - - -
- - -
- - - - - -一个主进程和多个工作进程，工作进程以非特权用户运行； - - - -支持的事件机制：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； - - - -众多支持的kqueue特性包括EV_CLEAR、EV_DISABLE（临时禁止事件）、NOTE_LOWAT、EV_EOF，可用数据的数量，错误代码； - - - -支持sendfile（FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5+）、sendfile64（Linux 2.4.21+）和sendfilev（Solaris 8 7/01+）； - - - -文件AIO（FreeBSD 4.3+, Linux 2.6.22+）； - - - -DIRECTIO -(FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, Mac OS X); - - - -支持Accept-filters（FreeBSD 4.1+, NetBSD 5.0+）和 TCP_DEFER_ACCEPT（Linux 2.4+）； - - - -10000个非活跃的HTTP keep-alive连接仅占用约2.5M内存； - - - -尽可能避免数据拷贝操作。 - - - - - -
- - -
- - - - - -FreeBSD 3 — 10 / i386; FreeBSD 5 — 10 / amd64; - - - -Linux 2.2 — 3 / i386; Linux 2.6 — 3 / amd64; - - - -Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; - - - -AIX 7.1 / powerpc; - - - -HP-UX 11.31 / ia64; - - - -MacOS X / ppc, i386; - - - -Windows XP, Windows Server 2003. - - - - - -
- - -
\ No newline at end of file diff --git a/xml/he/GNUmakefile b/xml/he/GNUmakefile deleted file mode 100644 --- a/xml/he/GNUmakefile +++ /dev/null @@ -1,4 +0,0 @@ -DOCS = \ - windows \ - http/server_names \ - http/converting_rewrite_rules \ diff --git a/xml/he/docs/http/converting_rewrite_rules.xml b/xml/he/docs/http/converting_rewrite_rules.xml deleted file mode 100644 --- a/xml/he/docs/http/converting_rewrite_rules.xml +++ /dev/null @@ -1,134 +0,0 @@ - - -
- -
- - -משתמשים שבמהלך חיי האירוח המשותף נהגו להגדיר הכל באמצעות -שימוש רק בקובצי htaccess. של Apache, יתרגמו בדרך כלל את -הכללים הבאים: - - -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; - rewrite ^ http://www.example.org$request_uri?; -} - -server { - listen 80; - server_name www.example.org; - ... -} - - - -
- - -
- - -דוגמה נוספת, במקום הגיון הפוך: כל מה שהוא לא -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.org www.example.org; - ... -} - -server { - listen 80 default_server; - server_name _; - rewrite ^ http://example.org$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/index.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; -} - - - -
- -
diff --git a/xml/he/docs/http/server_names.xml b/xml/he/docs/http/server_names.xml deleted file mode 100644 --- a/xml/he/docs/http/server_names.xml +++ /dev/null @@ -1,419 +0,0 @@ - - -
- -
- - -שמות שרת מוגדרים על ידי המאפיין server_name -והם קובעים איזה בלוק תצורת שרת מקובץ התצורה יהיה בשימוש לכל בקשה ובקשה לשרת. -ראו גם “”. -ניתן להגדירם באמצעות שמות מדוייקים, שמות Wildcard, או באמצעות ביטויים רגולריים: - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name *.example.org; - ... -} - -server { - listen 80; - server_name mail.*; - ... -} - -server { - listen 80; - server_name ~^(?<user>.+)\.example\.net$; - ... -} - - -השמות נבדקים בסדר הבא: - - - - -שמות מדוייקים; - - - -שמות Wildcard המתחילים בכוכבית: *.example.org; - - - -שמות Wildcard המסתיימים בכוכבית: mail.*; - - - -ביטויים רגולריים לפי הסדר שבו הם מופיעים בקובץ התצורה. - - - -ההתאמה הראשונה עוצרת את החיפוש. - - -
- - -
- - -שם wildcard יכול להכיל כוכבית רק בתחילת או בסוף השם, וחייב להיות בגבול של נקודה. -השמות www.*.example.org -ו w*.example.org הם שגויים. -למרות זאת, ניתן לציין שמות כאלה באמצעות ביטויים רגולריים, -לדוגמא, ~^www\..+\.example\.org$ ו -~^w.*\.example\.org$. -סימן הכוכבית יכול להחליף מספר חלקי שם. -השם *.example.org מתאים לא רק ל -www.example.org אלא גם ל www.sub.example.org. - - - -ניתן להשתמש ב wildcard מיוחד בצורה של .example.org -כדי להתאים גם לשם המדוייק example.org -וגם לשם ה wildcard הבא: *.example.org. - - -
- - -
- - -הביטויים הרגולריים ש nginx משתמש בהם, תואמים לאלה אשר נמצאים בשימוש -בשפת פרל (PCRE). -כדי להשתמש בביטוי רגולרי, על שם השרת להתחיל עם סימן הטילדה (~), כך: - - -server_name ~^www\d+\.example\.net$; - - -אחרת nginx יתייחס אליו כשם מדוייק, או אם הביטוי מכיל כוכבית, כשם wildcard (וסביר -להניח שיהיה שגוי). -אל תשכחו להגדיר עוגני - “^” ו “$”. -הם לא דרושים תחבירית, אם כי לוגית. -כמו כן שימו לב שהנקודות של שם המתלם צריכות להיות מוברחות (escaped) על ידי לוכסן הפוך (\). -ביטוי רגולרי המכיל את התווים “{” -ו “}” צריך להיות במרכאות: - - -server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; - - -אחרת nginx יכשל בעלייה, ויציג את הודעת השגיאה הבאה: - - -directive "server_name" is not terminated by ";" in ... - - -ביטוי רגולרי שניתן לו שם ונלכד, ניתן לשימוש מאוחר יותר כמשתנה: - - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - - -ספריית PCRE תומכת בלכידות מבוססות שם לפי התחביר הבא: - - - - - - - - - - - - - - - - - - -
?<name>תחביר תואם פרל 5.10, נתמך החל מ PCRE-7.0
?'name'תחביר תואם פרל 5.10, נתמך החל מ PCRE-7.0
?P<name>תחביר תואם פייתון, נתמך החל מ PCRE-4.0
- -אם nginx נכשל בעלייה ומציג את הודעת השגיאה הבאה: - - -pcre_compile() failed: unrecognized character after (?< in ... - - -פירוש הדבר שספריית ה PCRE היא ישנה, ועליכם לנסות את התחביר -?P<name>. - -את הלכידה ניתן לבצע גם בצורה ספרתית: - - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - - -אך יש להשתמש בצורה זו במקרים פשוטים (כמו לעיל), כיוון שהייחוסים הספרתיים -יכולים להידרס בקלות - - - -
- - -
- - -אם אף server_name לא מוגדר בבלוג שרת, -אזי nginx משתמש ב hostname בתור שם השרת. - - - -אם ברצונכם לעבד בקשות בלי שורת כותר “Host” -בבלוק שרת שאינו ברירת המחדל, עליכם לציין שם ריק: - - -server { - listen 80; - server_name example.org www.example.org ""; - ... -} - - - - -אם מישהו מבצע בקשה באמצעות כתובת IP במקום שם שרת, שורת הכותר -“Host” תכיל כתובת IP, ואפשר יהיה לטפל בבקשה על ידי -שימוש בכתובת IP בשם השרת: - - -server { - listen 80; - server_name example.org - www.example.org - "" - 192.168.1.1 - ; - ... -} - - - - -בדוגמאות catch-all ייתכן ותראו את השם המוזר “_”: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -אין שום דבר מוזר בשם הזה, הוא רק אחד משלל שמות מתחם שגויים שלעולם לא -תפגשו בהם בשם אמיתי. -ניתן להשתמש גם ב “--”, “!@#”, וכך הלאה. - - - -nginx בגירסאות עד 0.6.25 תמך בשם המיוחד “*” -אשר יש שפירשו אותו בטעות כשם catch-all. -השם הזה מעולם לא תפקד כ catch-all ואף לא כשם wildcard. -בפועל, הוא סיפק את הפונקציונליות שהיום מסופקת על ידי -המאפיין server_name_in_redirect. -השם המיוחד “*” הוא כעת לא מומלץ לשימוש, ויש -להשתמש במאפיין server_name_in_redirect במקומו. -שימו לב שאין דרך לציין את שם ה catch-all או את שרת ברירת המחדל -על ידי שימוש במאפיין server_name. -זוהי תכונה של המאפיין listen ולא של המאפיין server_name. -ראו גם “”. - -באפשרותכם להגדיר שרתים המאזינים על פורטים *:80 ו *:8080, -ולהגדיר שרת אחת שהוא ברירת המחדל עבור פורט - *:8080, בעוד שהשני יהיה ברירת מחדל עבור פורט *:80: - - -server { - listen 80; - listen 8080 default_server; - server_name example.net; - ... -} - -server { - listen 80 default_server; - listen 8080; - server_name example.org; - ... -} - - - - -
- - -
- - - -שמות מדוייקים ושמות wildcard מאוחסנים בגיבוב (hash). -הגיבובים מקושרים להאזנות לפורטים, ולכן פורט האזנה יכולים להיות -עד שלושה גיבויים: גיבוב שם מדוייק, גיבוי שמות wildcard שמתחילים -בכוכבית, וגיבוב שמות wildcard שמסתיימים בכוכבית. -הגודל של הגיבובים מיועל בשלב התצורה כך שניתן יהיה למצוא שם -עם הכי מעט פספוסי מטמון מעבד. -גיבוב השמות המדוייקים עובר חיפוש ראשון. -אם שם לא נמצא בגיבוב השמות המדוייק, מתחיל חיפוש בגיבוב השמות המתחילים -בכוכבית. -אם הוא לא נמצא גם שם, מתחיל חיפוש בגיבוב השמות המסתיימים בכוכבית. -חיפוש בגיבובי שמות wildcard הוא איטי יותר מחיפוש שם בגיבוב השמות המדוייקים -כיוון ששמות עוברים חיפוש על פי חלקי שם המתחם. -שימו לב שצורת ה wildcard המיוחדת .example.org -שמורה גם היא בגיבוב שמות ה wildcard ולא בגיבוב השמות המדוייקים. -ביטויים רגולריים נבדקים באופן סדרתי, ועל כן הם השיטה האיטית ביותר -ואינם סקאלאביליים. - - - -בהתחשב בנסיבות אלה, הכי טוב להשתמש בשמות מדוייקים בכל מקום שהדבר אפשרי. -לדוגמה, אם השמות הנפוצים ביותר לשרת הם example.org ו www.example.org, -יותר יעיל להגדיר אותם באופן מפורש: - - -server { - listen 80; - server_name example.org www.example.org *.example.org; - ... -} - - -מאשר להשתמש בשיטה המופשטת: - - -server { - listen 80; - server_name .example.org; - ... -} - - - - -אם הגדרתם מספר גדול של שמות שרת, או שהגדרתם שמות שרת ארוכים מהרגיל, -ייתכן ויהיה עליכם לכוונן את המאפיינים server_names_hash_max_size -ו server_names_hash_bucket_size ברמת ה http. -ערך ברירת המחדל של server_names_hash_bucket_size -יכול להיות שווה ל 32, ל 64, או לערך אחר, בהתאם לגודל קו המטמון של המעבד שלכם. -אם ברירת המחדל היא 32 ותגדירו -“too.long.server.name.example.org” בתור שם שרת, -אזי nginx ייכשל בעלייה ויציג את הודעת השגיאה הבאה: - - -could not build the server_names_hash, -you should increase server_names_hash_bucket_size: 32 - - -במקרה זה, עליכם להגדיר את ערך המאפיין לחזקה הבאה של 2: - - -http { - server_names_hash_bucket_size 64; - ... - - -אם הגדרתם כמות גדולה של שמות שרת, אתם עלולים לקבל את הודעת השגיאה הבאה: - - -could not build the server_names_hash, -you should increase either server_names_hash_max_size: 512 -or server_names_hash_bucket_size: 32 - - -עליכם לנסות קודם להגדיל את server_names_hash_max_size -למספר קרוב למספר השרתים. -רק אם זה לא עזר, או שזמן העלייה של nginx הוא ארוך בצורה מוגזמת, -נסו להגדיל את server_names_hash_bucket_size. - - - -אם שרת הוא השרת היחיד עבור פורט האזנה, אזי nginx לא יבדוק שמות שרת בכלל -(ולא יבנה גיבובים עבור פורט ההאזנה). -אך, יש יוצא דופן אחד. -אם server_name הוא ביטוי רגולרי עם לכידות, -nginx חייב לבצע את הביטוי כדי לקבל את מה שנלכד בהן. - - -
- - -
- - - - - -לכידת שמות בביטויים רגולריים נתמכה החל מגירסה 0.8.25. - - - -לכידת ביטויים רגולריים נתמכה החל מגירסה 0.7.40. - - - - -שם שרת ריק “” נתמך החל מגירסה 0.7.12. - - - -שם שרת מסוג wildcard או ביטוי רגולרי נתמכו לשימוש כשם שרת ראשון החל מגירסה 0.6.25. - - - -שמות שרת כביטוי רגולרי נתמכו החל מגירסה 0.6.7. - - - -צורות Wildcard מסוג example.* נתמכו החל מגירסה 0.6.0. - - - -הצורה המיוחדת .example.org נתמכה החל מגירסה 0.3.18. - - - -הצורה *.example.org נתמכה החל מגירסה 0.1.13. - - - - - -
- -
diff --git a/xml/he/docs/index.xml b/xml/he/docs/index.xml deleted file mode 100644 --- a/xml/he/docs/index.xml +++ /dev/null @@ -1,42 +0,0 @@ - - -
- - -
- - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - -
- -
diff --git a/xml/he/docs/windows.xml b/xml/he/docs/windows.xml deleted file mode 100644 --- a/xml/he/docs/windows.xml +++ /dev/null @@ -1,142 +0,0 @@ - - -
- -
- - -nginx/Windows משתמש ב API הטבעי של חלונות, Win32 API (ולא בשכבת אמולציה של Cygwin). -נכון למועד כתיבת שורות אלה, שיטת היידוע select היא זו שנמצאת בשימוש, -ולכן אין לצפות לרמת ביצועים גבוהה וליכולת גידול. -עקב כך וגם בעקבות בעיות ידועות אחרות, nginx/Windows נחשבת כגירסת בטא. -ישנה פונקציונליות כמעט מלאה ב nginx/Windows ביחס לגירסת Unix, חוץ מפילטר XSLT, -פילטר תמונות, מודול GeoIP ושפת Perl משובצת. - - -כדי להתקין את nginx/Windows, יש להוריד -את קובץ הזיפ של גירסת הפיתוח האחרונה , -כיוון שענף הפיתוח מכיל את כל התיקונים הידועים, בייחוד אלו הקשורים לחלונות. -אחרי ההורדה, יש לפרוס את קובץ הזיפ, -להיכנס לתיקיה nginx-, ולהריץ את nginx. -הנה דוגמא עבור תיקיית השורש של כונן C: - - -cd c:\ -unzip nginx-.zip -cd nginx- -start nginx - - -תוכלו להריץ את כלי שורת הפקודה tasklist כדי לראות תהליכים -של nginx: - - -C:\nginx->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 - - -אחד מהתהליכים הוא התהליך הראשי (מנהל), והאחר הוא תהליך עובד. -אם nginx לא מתחיל לפעול, יש לעיין בקובץ logs\error.log כדי לבדוק את הסיבה. -אם קובץ הלוג לא נוצר, הסיבה צריכה להיות מדווחת ב Event Log של חלונות. -אם הנכם מקבלים דף שגיאה במקום העמוד הרצוי, עליכם לעיין בקובץ logs\error.log גם כן, -כדי לראות מה הסיבה. - - - -nginx/Windows משתמש בתיקייה שממנה הוא הופעל בתור תיקיית הקידומת לכל -הנתיבים היחסיים שבקובץ התצורה. -בדוגמה שלעיל, תיקיית הקידומת תהיה -C:\nginx-\. -על נתיבים בקובץ התצורה להיות בסגנון Unix בלבד, באמצעות לוכסנים קדמיים: - - -access_log logs/site.log; -root C:/web/html; - - - - -nginx/Windows רץ כיישום קונסול סטנדרטי, ולא כשירות (service) במערכת, -וניתן לנהלו באמצעות הפקודות הבאות: - - - - - - - - - - - - - - - - - - - - - - -
nginx -s stopיציאה מהירה
nginx -s quitיציאה מסודרת
nginx -s reload -שינוי תצורה, -הפעלת תהליך עובד חדש, -סגירת תהליך עובד ישן באופן מסודר -
nginx -s reopenפתיחה מחדש של קובצי הלוג
- - -
- -
- - - - -למרות שניתן להפעיל מספר תהליכים עובדים, רק אחד מהם עושה בפועל את העבודה. - - - -תהליך עובד לא יכול לטפל ביותר מ 1024 חיבורים פעילים בו זמנית. - - - -מודול המטמון ומודולים אחרים אשר דורשים תמיכה בזיכרון משותף, לא עובדים בחלונות -ויסטה או גירסאות מאוחרות יותר, עקב הפעלת טכניקת address space layout randomization -המופעלת בגירסאות אלה של חלונות. - - - - -
- -
- - - - -הרצה כשירות במערכת (Service). - - - -שימוש ב I/O completion ports כשיטת יידוע. - - - -שימוש במספר נימי עובדים בתוך תהליך עובד אחד. - - - - -
- -
diff --git a/xml/he/index.xml b/xml/he/index.xml deleted file mode 100644 --- a/xml/he/index.xml +++ /dev/null @@ -1,266 +0,0 @@ - - -
- - -
- - -nginx [נהגה: engine x] הוא שרת HTTP ופרוקסי הפוך, כמו גם שרת פרוקסי לדואר, -שנכתב על ידי Igor Sysoev. - הוא נמצא בשימוש כבר יותר מחמש שנים באתרים רוסיים עמוסים במיוחד, כגון -Rambler -(ו RamblerMedia.com). -לפי חברת Netcraft, השרת nginx הגיש או נתן שירות ל -4.70% -מהאתרים העמוסים ביותר באפריל 2010. -הנה כמה סיפורי הצלחה: -FastMail.FM, -Wordpress.com. - - - -קוד המקור הוא בעל רשיון -2-פיסקאות דמוי רשיון BSD. - - -
- - -
- - - - - -הגשת קבצים סטטיים וקובצי אינדקס, ואינדוקס אוטומטי; -מטמון file descriptor-ים פתוחים; - - - -פרוקסי הפוך מואץ כולל מטמון; -ביזור עומסים פשוט ושרידות מפני תקלות; - - - -תמיכה בהאצה עם מטמון של שרתי FastCGI מרוחקים; -ביזור עומסים פשוט ושרידות מפני תקלות; - - - -ארכיטקטורה מודולרית. פילטרים המבצעים gzip, טווחי בתים (byte ranges), -תשובות מסוג chunked, תמיכה ב XSLT, SSI ופילטר שינוי גודל תמונות. -ריבוי הכללות SSI בדף בודד יכול להיות מבוצע באופן מקבילי אם הן מטופלות -על ידי FastCGI או שרתים ש nginx הוא פרוקסי עבורם. - - - -תמיכה ב SSL ו TLS SNI. - - - - - -
- - -
- - - - - -שרתים וירטואליים מבוססי IP ושם (הוסט); - - - -תמיכה ב keep-alive וב pipelining לחיבורים; - - - -תצורה גמישה; - - - -קביעת תצורה מחדש ואף שדרוג מקוון ללא כל הפרעה לעיבוד -בקשות הלקוחות; - - - -פורמטים ללוג הגישה, כתיבה ללוג באמצעות חוצץ, והחלפת לוגים מהירה; - - - -הפנייה באמצעות קודי שגיאה 3xx-5xx; - - - -מודול rewrite; - - - -בקרת גישה המבוססת על כתובת IP של הלקוח וגם אימות מסוג HTTP Basic; - - - -המתודות PUT, DELETE, MKCOL, COPY ו MOVE; - - - -סטרימינג של FLV; - - - -הגבלת מהירות; - - - -הגבלה של מספר החיבורים בו זמנית או מספר הבקשות מכתובת אחת. - - - -perl משובץ. - - - - - -
- - -
- - - - - -הפניית משתמשים לשרתי IMAP/POP3 אחוריים בהתבסס על שרת אימות HTTP חיצוני; - - - -אימות משתמש באמצעות שרת אימות HTTP חיצוני והפניית חיבור לשרת SMTP פנימי; - - - -מתודות אימות: - - - - -POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -SMTP: AUTH LOGIN/PLAIN/CRAM-MD5; - - - - - - -תמיכה בהצפנת SSL; - - - -תמיכה ב STARTTLS ו STLS. - - - - - -
- - -
- - - - - -תהליך ראשי אחד ומספר תהליכי עובדים. -תהליכי העובדים רצים בתור משתמש ללא הרשאות; - - - -שיטות יידוע: kqueue (במערכות FreeBSD 4.1 ומעלה), -epoll (במערכות לינוקס 2.6 ומעלה), סיגנלי rt (במערכות לינוקס 2.2.19 ומעלה), -/dev/poll (במערכות סולאריס 7 11/99 ומעלה), event ports (במערכות סולאריס 10), -select, ואף poll; - - - -תמיכה עבור תכונות kqueue שונות כולל EV_CLEAR ו EV_DISABLE -(כדי לבטל אירועים זמנית), NOTE_LOWAT, EV_EOF, מספר קודי מידע ושגיאה; - - - -תמיכה ב sendfile (במערכות FreeBSD 3.1 ומעלה, לינוקס 2.2 ומעלה ו Mac OS X 10.5), תמיכה ב sendfile64 (לינוקס 2.4.21 ומעלה), -ו sendfilev (סולאריס 8 7/01 ומעלה); - - - -File AIO (במערכות FreeBSD 4.3 ומעלה ולינוקס 2.6.22 ומעלה); - - - -תמיכה ב Accept-filters (במערכות FreeBSD 4.1 ומעלה) ו TCP_DEFER_ACCEPT (במערכות לינוקס 2.4 ומעלה) - - - -10,000 חיבורי HTTP לא פעילים במצב keep-alive תופסים נפח זיכרון העומד על בערך -12.5M; - - - -פעולות העתקת מידע מבוצעות באופן נדיר ככל האפשר. - - - - - -
- - -
- - - - - -FreeBSD 3—8 / i386; FreeBSD 5—8 / amd64; - - - -לינוקס 2.2—2.6 / i386; לינוקס 2.6 / amd64; - - - -סולאריס 9 / i386, sun4u; סולאריס 10 / i386, amd64, sun4v; - - - -MacOS X / ppc, i386; - - - -חלונות XP, חלונות סרבר 2003. - - - - - -
- - -
diff --git a/xml/i18n.xml b/xml/i18n.xml --- a/xml/i18n.xml +++ b/xml/i18n.xml @@ -43,47 +43,4 @@ for recent changes. для ознакомления с последними изменениями. - -和 -作者: -编辑: -翻译: -语法 -默认值 -上下文 -任意 -这个指令出现在版本 -这个指令出现在版本 -指令目录 -翻译内容可能已经过旧。 -你可以通过 英文版本 -查看最近的更新。 - - - -作成: -翻訳: - - - -נכתב על ידי -תורגם על ידי - - - -yazan: -çeviren: - - - -e -scritto da -a cura di -tradotto da -Elenco alfabetico delle direttive -Questa traduzione potrebbe essere obsoleta. -Verifica la versione in inglese -per gli aggiornamenti piu' recenti. - - diff --git a/xml/it/GNUmakefile b/xml/it/GNUmakefile deleted file mode 100644 --- a/xml/it/GNUmakefile +++ /dev/null @@ -1,21 +0,0 @@ -DOCS = \ - install \ - windows \ - events \ - syntax \ - control \ - hash \ - http/request_processing \ - http/server_names \ - http/configuring_https_servers \ - debugging_log \ - http/converting_rewrite_rules \ - howto_build_on_win32 \ - contributing_changes \ - beginners_guide \ - configure \ - -TOP = \ - download \ - support \ - linux_packages \ diff --git a/xml/it/docs/beginners_guide.xml b/xml/it/docs/beginners_guide.xml deleted file mode 100644 --- a/xml/it/docs/beginners_guide.xml +++ /dev/null @@ -1,454 +0,0 @@ - - - - -
- -
- - -La presente guida fornisce una introduzione a nginx e descrive alcune -semplici funzionalità per il quale può essere utilizzato. -Nel seguito si presuppone che nginx sia gia' stato installato; -in caso contrario fare riferimento alla pagina -. -La presente guida spiega come avviare, come fermare e come ricaricare -la configurazione di nginx, descrive brevemente la struttura del file -di configurazione, spiega come configurare nginx per servire contenuti statici, -come configurarlo per l'uso come proxy server, -e come configurarlo per l'uso con un'applicazione FastCGI. - - - -nginx ha un processo master e numerosi processi worker: -lo scopo principale del processo master e' leggere e interpretare la configurazione, -e mantenere i processi worker attivi; -a loro volta, i processi worker si occupano di gestire effettivamente le richieste. -nginx utilizza un modello event-based e meccanismi dipendenti dal sistema operativo -per distribuire con efficienza le richieste fra i processi worker. -Il numero di processi worker e' definito nel file di configurazione, -e puo' sia essere fisso, -sia essere regolato automaticamente in base al numero di core CPU disponibili -(vedere ). - - - -La maniera in cui nginx e i suoi moduli lavorano e' determinata nel file di configurazione; -per default, tale file si chiama -nginx.conf -e si trova in una delle directory: -/usr/local/nginx/conf , -/etc/nginx , -/usr/local/etc/nginx . - - -
- - -
- - -Per far partire nginx, avviare il file eseguibile. -Una volta partito, nginx puo' essere controllato invocando l'eseguibile con il parametro --s . -Usare la seguente sintassi: - -nginx -s signal - -Dove signal e' uno dei seguenti: - - -stop—arresto rapido - - -quit—arresto controllato - - -reload—ricaricamento della configurazione - - -reopen—riapertura del file di log - - -Ad esempio, per fermare il processo nginx ma attendendo che finisca di servire -le richieste correnti, va eseguito il seguente comando: - -nginx -s quit - -Questo comando dovrebbe essere eseguito dallo stesso utente che ha avviato nginx. - - - -Le modifiche al file di configurazione non saranno applicate sinche' -nginx non e' riavviato o non riceve il comando di ricaricamento della configurazione. -Per ricaricare la configurazione, eseguire: - -nginx -s reload - - - - -Quando il processo master riceve il segnale di ricaricamento della configurazione, -verifica la validita' sintattica e tenta di applicare la configurazione riportata nel relativo file. -Se ha successo, il processo master avvia nuovi processi worker e invia messaggi di chiusura a quelli vecchi, -che smettono di accettare nuove connessioni ma continuano a servire le richieste correnti sinche' non sono -state del tutto completate, dopo di che terminano. -Se la nuova configurazione non risulta corretta, oppure se non e' possibile applicarla, -il processo master continua a lavorare con la configurazione precedente. - - - -E' anche possibile inviare un segnale ai processi nginx tramite i normali comandi Unix, -quale ad esempio kill, che invia un segnale al processo individuato tramite il relativo ID; -per default, l'ID del processo master di nginx e' scritto nel file nginx.pid -nella directory -/usr/local/nginx/logs oppure -/var/run . -Ad esempio, se l'ID del processo master e' 1628, per inviare il segnale QUIT, -che causa l'arresto controllato, bisogna eseguire il comando: - -kill -s QUIT 1628 - -Per ottenere la lista di tutti in processi nginx, e' possibile usare vari comandi, -fra cui ad esempio ps -nella maniera seguente: - -ps -ax | grep nginx - -Per ulteriori informazioni su come inviare segnali a nginx, fare riferimento a -. - - -
- - -
- - -nginx e' costituito da moduli che sono controllati da direttiva specificate -nel file di configurazione. -Le direttive possono essere semplici o a blocco. -Una direttiva semplice e' caratterizzata dal nome seguito da parametri separati da spazi, -e termina con punto e virgola (;). -Una direttiva a blocco ha la stessa struttura di una direttiva semplice, -ma, invece che con punto e virgola, termina con un insieme di istruzioni aggiuntive racchiuse -fra parentesi graffe ( { e } ). -Una direttiva che puo' avere altre direttive all'interno delle parentesi graffe e' chiamata -contesto (ad esempio: -, -, -, -e -). - - - -Le direttive del file di configurazione che non sono all'interno di alcun -contesto sono considerate facenti parte del contesto -main. -Le direttive events e http -appartengono al contesto main, la direttiva server -al contesto http, -la direttiva location al contesto server. - - - -Tutto cio' che in una riga segue il simbolo # e' considerato un commento. - - -
- - -
- - -Un compito importante di un web server e' costituito dal servizio -di file, quali immagini o pagine HTML statiche. -Di seguito si implementa un esempio in cui, a seconda della richiesta, -i file sono serviti prendendoli da varie directory locali: /data/www -(che puo' contenere file HTML) e /data/images -(che contiene immagini). -Per tale implementazione e' necessaria la modifica del file di configurazione, -con l'aggiunta, -all'interno di un blocco , -di un blocco -a sua volta contenente due blocchi . - - - -Anzitutto, creare le directory /data/www e /data/images, -e aggiungere nella prima un file index.html contenente un testo qualsiasi, -nella seconda una immagine a caso. - - - -Quindi, aprire il file di configurazione; -si puo' notare che contiene gia' diversi esempi di blocchi server, -per la maggior parte inattivati da commenti; -inattivare con commenti tutto il blocco http, e scriverne uno nuovo: - -http { - server { - } -} - -In generale, il file di configurazione puo' includere numerosi blocchi server, -distinti in base alla porta su cui -sono in ascolto e al -nome del server. -Una volta che nginx ha deciso quale server deve processare una data richiesta, -confronta l'URI presente nell'header della stessa con i parametri delle direttive -location definite all'interno del blocco server. - - - -Aggiungere il seguente blocco location -al blocco server: - -location / { - root /data/www; -} - -Questo blocco location fa riferimento al prefisso “/”, -da confrontare con l'URI della richiesta: -se la richiesta corrisponde, l'URI viene aggiunto al path specificato dalla -direttiva , -in questo caso cioe' a /data/www , -per definire sul file system locale il path al file richiesto. -Se i blocchi location che corrispondono sono piu' di uno, -nginx seleziona quello con il prefisso piu' lungo; -il blocco location dell'esempio riguarda il prefisso -piu' breve in assoluto, di lunghezza uno, quindi e' effettivamente usato -solo se tutti gli altri blocchi location non corrispondono. - - - -Tornando all'esempio, aggiungere un secondo blocco location: - -location /images/ { - root /data; -} - -In questo caso ci sara' corrispondenza con -le richieste che iniziano con /images/ -(anche location / corrisponde alla richiesta, -ma ha un prefisso piu' breve e quindi priorita' inferiore). -La configurazione risultante del blocco server risulta quindi: - -server { - location / { - root /data/www; - } - - location /images/ { - root /data; - } -} - -Tale configurazione e' effettivamente funzionante, -con il server in ascolto sulla porta standard 80 e accessibile -sulla macchina locale a http://localhost/ . -In risposta alle richieste di URI che iniziano con /images/ , -il server inviera' file presi dalla directory /data/images ; -ad esempio, in risposta ad una richiesta -http://localhost/images/example.png -nginx inviera' il file /data/images/example.png . -Se tale file non esiste, nginx inviera' una risposta che indica -l'errore 404. -Richieste di URI che non iniziano con /images/ -saranno mappate sulla directory /data/www ; -ad esempio, in risposta ad una richiesta -http://localhost/some/example.html -nginx inviera' il file /data/www/some/example.html . - - - -Per applicare la nuova configurazione, avviare nginx se e' spento; -se e' gia' attivo, inviare il segnale reload al processo master, -eseguendo: - -nginx -s reload - - - - - -Nel caso in cui qualcosa non vada come atteso, e' possibile cercare -di capire cosa e' successo verificandolo nei file access.log e -error.log, presenti nella directory /usr/local/nginx/logs o -/var/log/nginx . - - - -
- - -
- - -Uno degli usi piu' frequenti di nginx prevede la configurazione come proxy server, -vale a dire un server che riceve le richieste dai client, le passa ai server remoti, -riceve da essi le risposte, e le reinvia ai client. - - - -Di seguito si configura un semplice proxy server, il quale serve le richieste -di immagini con file da una directory locale, e invia invece tutte le altre -richieste a un ulteriore server web. -Nell'esempio, entrambi i server saranno definiti su una singola istanza di nginx.. - - - -Per iniziare, definire il server web aggiuntivo inserendo nel file di configurazione di -nginx un ulteriore blocco server con il contenuto seguente: - -server { - listen 8080; - root /data/up1; - - location / { - } -} - -Si tratta di un semplice server in ascolto sulla porta 8080 -(in precedenza la direttiva listen non e' stata specificata -in quanto e' stata usata la porta standard 80), che mappa tutte le -richieste sulla directory /data/up1 del file system locale. -Creare tale directory, e inserire in essa un file index.html . -Notare che la direttiva root e' posta nel -contesto server ; tale direttiva root e' usata -quando il blocco location scelto per servire una richiesta -non include una direttiva root propria. - - - -Procedere usando la configurazione del server della sezione precedente e -modificandola per farne un proxy server. -Nel primo blocco location, inserire la direttiva - -specificando come parametro il protocollo, il nome e la porta del server -web aggiuntivo (in questo caso http://localhost:8080 ): - -server { - location / { - proxy_pass http://localhost:8080; - } - - location /images/ { - root /data; - } -} - - - - -A questo punto modificare il secondo blocco location, che al momento -mappa le richieste con il prefisso /images/ sui file nella directory -/data/images , per fare in modo che risponda alle richieste con le -tipiche estensioni file delle immagini. -Il blocco location sara' il seguente: - -location ~ \.(gif|jpg|png)$ { - root /data/images; -} - -Il parametro e' una espressione regolare che corrisponde a tutti gli URI -che terminano con .gif, .jpg, o .png -(in nginx le espressioni regolari normalmente iniziano con ~). -La richiesta corrispondente sara' mappata sulla directory /data/images . - - - -Per decidere quale blocco location debba servire una richiesta, -nginx per prima cosa verifica le direttive - -che riportano la specifica di un prefisso, registrando quella con il piu' lungo -prefisso che corrisponde, quindi verifica quelle con una espressione regolare; -se c'e' corrispondenza con una espressione regolare, nginx sceglie tale -location, altrimenti sceglie quella registrata in precedenza. - - - -Alla fine la configurazione risultante di un proxy server e' la seguente: - -server { - location / { - proxy_pass http://localhost:8080/; - } - - location ~ \.(gif|jpg|png)$ { - root /data/images; - } -} - -Tale server selezionera' le richieste che terminano in .gif, -.jpg o .png e le mappera' sulla directory -/data/images (aggiungendo l'URI al parametro della direttiva -root), mentre invece passera' tutte le altre richieste al web -server configurato in precedenza. - - - -Per applicare la nuova configurazione, inviare il segnale reload -ad nginx, come descritto nella sezione precedente. - - - -Ci sono molte more -direttive che possono essere usate nella configurazione di un proxy. - - -
- - -
- - -nginx puo' essere usato per dirigere le richieste ad uno o piu' server -FastCGI che eseguono applicazioni scritte con vari framework e linguaggi di -programmazione, ad esempio PHP. - - - -La configurazione piu' semplice di nginx che consente di lavorare con un server -FastCGI, richiede l'uso della direttiva - -al posto della direttiva proxy_pass, -e della direttiva -per impostare i parametri passati al server FastCGI. -Nel seguito si suppone che il server FastCGI sia accessibile a localhost:9000 . -Prendendo la configurazione di un proxy nella sezione precedente come base, -sostituire la direttiva proxy_pass con la direttiva fastcgi_pass -e cambiare il relativo parametro in localhost:9000 . -Nel caso del PHP, il parametro SCRIPT_FILENAME e' usato per determinare -il nome dello script, ed il parametro QUERY_STRING e' usato per -passare i parametri della richiesta. -La configurazione risulta quindi: - -server { - location / { - fastcgi_pass localhost:9000; - fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; - fastcgi_param QUERY_STRING $query_string; - } - - location ~ \.(gif|jpg|png)$ { - root /data/images; - } -} - -Tale configurazione realizza un server che inoltra tutte le richieste -(a parte quelle per immagini statiche) tramite il protocollo FastCGI -ad un server esterno che opera su -localhost:9000 . - - -
- -
diff --git a/xml/it/docs/configure.xml b/xml/it/docs/configure.xml deleted file mode 100644 --- a/xml/it/docs/configure.xml +++ /dev/null @@ -1,263 +0,0 @@ - - - - -
- -
- - -La compilazione si configura tramite il comando configure, -che definisce vari aspetti del sistema, fra cui i metodi che nginx puo' -usare per processare le connessioni; alla fine viene creato un Makefile. -Il comando configure supporta, fra gli altri, i seguenti parametri: - - - - ---prefix=path— -definisce la directory che conterra' i file del server. -La medesima directory sara' pure usata per tutti i path relativi -definiti da configure (a parte i path ai sorgenti -delle librerie) e nel file di configurazione nginx.conf. -Per default vale /usr/local/nginx. - - - - - ---sbin-path=path— -stabilisce il nome del file eseguibile di nginx. -Tale valore e' usato solo nel corso dell'installazione. -Per default il file eseguibile e' chiamato -prefix/sbin/nginx. - - - - - ---conf-path=path— -stabilisce il nome del file di configurazione nginx.conf. -In ogni caso, nginx puo' sempre essere avviato con un file di -configurazione differente, specificando quest'ultimo tramite il parametro -a linea di comando -c file. -Per default il file di configurazione e' -prefix/conf/nginx.conf. - - - - - ---pid-path=path— -stabilisce il nome del file nginx.pid in cui e' registrato l'ID -del processo principale. -Dopo l'installazione, il nome del file puo' sempre essere modificato -tramite la direttiva -del file di configurazione nginx.conf. -Per default il file contenente il pid e' -prefix/logs/nginx.pid. - - - - - ---error-log-path=path— -stabilisce il nome del principale file di diagnostica in cui sono -registrati gli errori e gli avvisi. -Dopo l'installazione, il nome del file puo' sempre essere modificato -tramite la direttiva -del file di configurazione nginx.conf. -Per default il file degli errori e' -prefix/logs/error.log. - - - - - ---http-log-path=path— -stabilisce il nome del principale file di log delle richieste -al server HTTP. -Dopo l'installazione, il nome del file puo' sempre essere modificato tramite -la direttiva -del file di configurazione nginx.conf. -Per default il file di log delle richieste e' -prefix/logs/access.log. - - - - - ---user=name— -stabilisce il nome di un utente non privilegiato le cui credenziali saranno -usate dai processi worker. -Dopo l'installazione, l'utente puo' sempre essere modificato tramite -la direttiva -del file di configurazione nginx.conf. -L'utente di default e' nobody. - - - - - ---group=name— -stabilisce il nome di un gruppo le cui credenziali saranno -usate dai processi worker. -Dopo l'installazione, il gruppo puo' sempre essere modificato tramite -la direttiva -del file di configurazione nginx.conf. -Per default il gruppo e scelto fra uno di quelli degli utenti non priviliegiati. - - - - - ---with-select_module
---without-select_module— -abilita o disabilita la compilazione del modulo che consente al server -di utilizzare il metodo select. -Tale modulo e' compilato automaticamente nel caso in cui la piattaforma non -supporti metodi piu' appropriati, quali kqueue, epoll, rtsig, o /dev/poll. - - - - - ---with-poll_module
---without-poll_module— -abilita o disabilita la compilazione del modulo che consente al server -di utilizzare il metodo poll. -Tale modulo e' compilato automaticamente nel caso in cui la piattaforma non -supporti metodi piu' appropriati, quali kqueue, epoll, rtsig, o /dev/poll. - - - - - ---without-http_gzip_module— -disabilita la compilazione del modulo che -comprime le risposte -del server HTTP. -Per la compilazione e l'utilizzo di questo modulo e' richiesta la libreria zlib. - - - - - ---without-http_rewrite_module— -disabilita la compilazione del modulo che consente al server HTTP di -redirigere e cambiare l'URI -delle richieste. -Per la compilazione e l'utilizzo di questo modulo e' richiesta la libreria PCRE. - - - - - ---without-http_proxy_module— -disabilita la compilazione del -modulo di proxy -del server HTTP. - - - - - - ---with-http_ssl_module— -abilita la compilazione del modulo che aggiunge al server HTTP il -supporto al protocollo HTTPS. -Per default tale modulo non e' compilato. -Per la compilazione e l'utilizzo di questo modulo e' richiesta la libreria OpenSSL. - - - - - ---with-pcre=path— -indica il path ai sorgenti della libreria PCRE. -E' necessario scaricare dal sito di PCRE -la distribuzione della libreria (versioni da 4.4 a 8.32), ed estrarla. -Al resto ci pensano i comandi ./configure e -make di nginx. -La libreria e' richiesta per il supporto alle espressioni regolari nella -direttiva e per il -modulo ngx_http_rewrite_module. - - - - - ---with-pcre-jit— -compila la libreria PCRE con il supporto “just-in-time" -(1.1.12, direttiva ). - - - - - ---with-zlib=path— -indica il path ai sorgenti della libreria zlib. -E' necessario scaricare dal sito di zlib -la distribuzione della libreria (versioni da 1.1.3 a 1.2.7), ed estrarla. -Al resto ci pensano i comandi ./configure e -make di nginx. -La libreria e' richiesta per il modulo -ngx_http_gzip_module. - - - - - ---with-cc-opt=parameters— -definisce i parametri che saranno aggiunti alla variabile CFLAGS. -Nel caso in cui si stia usando la libreria PCRE in ambiente FreeBSD, -bisognerebbe specificare --with-cc-opt="-I /usr/local/include". -Se il numero di file supportati da select deve essere -incrementato, e' possibile farlo anche con questo parametro, ad esempio con: ---with-cc-opt="-D FD_SETSIZE=2048". - - - - - ---with-ld-opt=parameters— -definisce i parametri aggiuntivi che saranno usati durante il linking. -Nel caso in cui si stia usando la libreria PCRE in ambiente FreeBSD, -bisognerebbe specificare --with-ld-opt="-L /usr/local/lib". - - - - - - - - -Un esempio d'uso dei parametri (da scrivere tutti su un'unica linea): - -./configure - --sbin-path=/usr/local/nginx/nginx - --conf-path=/usr/local/nginx/nginx.conf - --pid-path=/usr/local/nginx/nginx.pid - --with-http_ssl_module - --with-pcre=../pcre-4.4 - --with-zlib=../zlib-1.1.3 - - - - -Dopo la configurazione, nginx e' compilato ed installato tramite -il comando make. - - -
- -
diff --git a/xml/it/docs/contributing_changes.xml b/xml/it/docs/contributing_changes.xml deleted file mode 100644 --- a/xml/it/docs/contributing_changes.xml +++ /dev/null @@ -1,148 +0,0 @@ - - - - - - -
- -
- - -Il codice sorgente e' gestito tramite -Mercurial. -L'archivio puo' essere -clonato con il comando: - -hg clone http://hg.nginx.org/nginx - - - -
- - -
- - -Il codice delle modifiche dovrebbe essere formattato secondo lo stile di nginx. -La formattazione non deve fare affidamento su caratteristiche proprie -dell'editor, dovrebbe invece seguire alcune regole base: - - - -la larghezza del testo non deve superare gli 80 caratteri - - - -l'indentazione va ottenuta con blocchi di quattro spazi - - - -non va usato il tab (tabulatore) - - - -in un file, i diversi blocchi logici di codice vanno separati con due linee vuote - - - -E' bene esaminare il codice di nginx esistente, e cercare di riprodurne lo stile -di formattazione nel proprio codice: e' piu' facile che una modifica sia accettata -se lo stile e' simile a quello del resto del codice. - - - -L'esecuzione di un commit sulle modifiche crea un -changeset -Mercurial; bisogna assicurarsi che siano corretti l'indirizzo -e-mail -e il nome dell'autore delle modifiche. - - - -Il messaggio di commit dovrebbe avere una breve descrizione su riga singola -(preferibilmente non piu' lunga di 67 caratteri), -seguita da una riga vuota e da una descrizione piu' lunga. -Il risultante changeset puo' essere ottenuto sotto forma di patch -tramite il comando hg export: - -# HG changeset patch -# User Filipe Da Silva <username@example.com> -# Date 1368089668 -7200 -# Thu May 09 10:54:28 2013 +0200 -# Node ID 2220de0521ca2c0b664a8ea1e201ce1cb90fd7a2 -# Parent 822b82191940ef309cd1e6502f94d50d811252a1 -Mail: removed surplus ngx_close_connection() call. - -It is already called for a peer connection a few lines above. - -diff -r 822b82191940 -r 2220de0521ca src/mail/ngx_mail_auth_http_module.c ---- a/src/mail/ngx_mail_auth_http_module.c Wed May 15 15:04:49 2013 +0400 -+++ b/src/mail/ngx_mail_auth_http_module.c Thu May 09 10:54:28 2013 +0200 -@@ -699,7 +699,6 @@ ngx_mail_auth_http_process_headers(ngx_m - - p = ngx_pnalloc(s->connection->pool, ctx->err.len); - if (p == NULL) { -- ngx_close_connection(ctx->peer.connection); - ngx_destroy_pool(ctx->pool); - ngx_mail_session_internal_server_error(s); - return; - - - -
- - -
- - -E' bene tenere in considerazione alcuni punti: - - - -Le modifiche proposte dovrebbero funzionare correttamente sul piu' ampio -numero possibile di -piattaforme supportate. - - - -Bisogna spiegare chiaramente perche' e' necessaria la modifica proposta, -e se possibile fornire un esempio. - - - - - -
- - -
- - -Le proposte di modifica vanno inviate alla mailing list degli -sviluppatori di nginx. -L'estensione -patchbomb -e' la maniera preferibile e piu' comoda di sottoporre i changeset. - - -
- - -
- - -Se si sottopone una proposta di modifica, automaticamente al progetto -viene concesso il permesso di utilizzarla in base ad una opportuna -licenza. - - -
- -
diff --git a/xml/it/docs/control.xml b/xml/it/docs/control.xml deleted file mode 100644 --- a/xml/it/docs/control.xml +++ /dev/null @@ -1,282 +0,0 @@ - - - - -
- -
- - -nginx puo' essere controllato tramite segnali. -L'ID del processo master e' scritto per default nel file -/usr/local/nginx/logs/nginx.pid. -E' possibile utilizzare un altro file utilizzando la direttiva -, definendola all'avvio -oppure in nginx.conf . -Il processo master riconosce i seguenti segnali: - - - - - - - - - - -
TERM, INTarresto rapido
QUITarresto controllato
HUPricaricamento della configurazione, -allineamento ad una diversa zona oraria (solo per FreeBSD e Linux), -riavvio di nuovi processi worker con una nuova configurazione, -spegnimento controllato dei vecchi processi worker
USR1riapertura dei file di log
USR2aggiornamento del file eseguibile
WINCHarresto controllato dei processi worker
- - - - -E' anche possibile controllare ciascun processo worker, -per quanto cio' non sia richiesto. -I segnali riconosciuti sono: - - - - - - - - -
TERM, INTarresto rapido
QUITarresto controllato
USR1riapertura dei file di log
WINCHchiusura anomala per debugging -(richiede ) -
- - - -
- - -
- - -Per far rileggere la configurazione a nginx, bisogna inviare -un segnale HUP al processo master. -Tale processo per prima cosa verifica la validita' sintattica -della nuova configurazione, quindi tenta di applicarla, vale a dire -di aprire i file di log e i nuovi socket di ascolto. -In caso di fallimento, annulla i cambiamenti e continua a lavorare -con la vecchia configurazione. -Invece, in caso di successo, avvia nuovi processi worker e invia a -quelli vecchi appositi segnali per chiederne l'arresto controllato. -I vecchi processi chiudono i socket di ascolto, ma continuano il -servizio per i vecchi client. -Quanto tutti i vecchi client sono stati servizi, i vecchi -processi worker terminano. - - - -Di seguito si illustra con un esempio. -Si immagini che nginx sia in esecuzione su FreeBSD 4.x -e che il comando - -ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)' - -produca il seguente risultato: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx -33127 33126 nobody 0.0 1380 kqread nginx: worker process (nginx) -33128 33126 nobody 0.0 1364 kqread nginx: worker process (nginx) -33129 33126 nobody 0.0 1364 kqread nginx: worker process (nginx) - - - - -Se al processo master si invia il segnale HUP, si ottiene: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx -33129 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx) -33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) - - - - -Uno dei vecchi processi worker con PID 33129 continua ad essere attivo; -dopo un po', esce: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx -33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -33135 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) - - - -
- - -
- - -Per poter ruotare i file di log, e' prima necessario cambiare loro il nome, -quindi bisogna inviare il segnale USR1 al processo master, -il quale provvede a riaprire tutti i file di log correnti e ad -assegnarli all'utente non privilegiato sotto i quali sono in -esecuzione i processi worker. -Dopo aver riaperto con successo i file, il processo master chiude tutti -i file aperti, ed invia un messaggio ai processi worker per chiedere loro -di riaprire i file; i processi worker provvedono quindi immediatamente -ad aprire i nuovi file ed a chiudere i vecchi. -Come risultato, i vecchi file sono quasi immediatamente disponibili per -eventuali attivita' successive, ad esempio per la compressione. - - -
- - -
- - -Per poter aggiornare l'eseguibile del server, prima e' necessario -porre il nuovo file al posto del vecchio; dopo, bisogna inviare al -processo master il segnale USR2. -Il processo master provvede a rinominare il file contenente il proprio -ID di processo, aggiungendo il suffisso .oldbin, ad -esempio /usr/local/nginx/logs/nginx.pid.oldbin, -quindi avvia un nuovo file eseguibile, che a sua volta fa partire i -propri processi worker: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx -33134 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -33135 33126 nobody 0.0 1380 kqread nginx: worker process (nginx) -33136 33126 nobody 0.0 1368 kqread nginx: worker process (nginx) -36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx -36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) - - - - - - -A questo punto, sia i processi worker relativi al vecchio eseguibile, sia quelli -relativi al nuovo, accettano richieste. -Se al processo master e' inviato il segnale WINCH, tutti i relativi processi -worker ricevono a loro volta un segnale che chiede loro l'arresto controllato, -e quindi iniziano a spegnersi: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx -33135 33126 nobody 0.0 1380 kqread nginx: worker process is shutting down (nginx) -36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx -36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) - - - - - -Quando su Linux si usa il metodo "rtsig", i nuovi processi potrebbero non -accettare connessioni anche dopo che al processo master vecchio e' stato -inviato il segnale WINCH. -In tal caso, bisogna continuare ad inviare il segnale USR1 al nuovo processo -master, sinche' i nuovi processi iniziano ad accettare connessioni. - - - - -In breve, i soli processi worker a processare le richieste saranno quelli nuovi: - - PID PPID USER %CPU VSZ WCHAN COMMAND -33126 1 root 0.0 1164 pause nginx: master process /usr/local/nginx/sbin/nginx -36264 33126 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx -36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) - - - - -Si noti che il vecchio processo master non chiude i suoi socket di ascolto, -e che se necessario e' possibile chiedergli di riavviare i propri -processi worker. -Se per qualche ragione il nuovo file eseguibile non lavora correttamente, -e' possibile procedere in due modi: - - - - -inviare il segnale HUP al vecchio processo master. -Il vecchio processo master provvedera' ad avviare -nuovi processi worker, senza rileggere la configurazione. -A questo punto, tutti i nuovi processi possono essere fermati -in maniera controllata, inviando il segnale QUIT al nuovo -processo master. - - - - - -inviare il segnale TERM al nuovo processo master. -Tale processo inviare a sua volta un messaggio ai suoi processi -worker che causera' la loro chiusura immediata. -(Se per qualche ragione i nuovi processi non terminano, e' -possibile inviare loro il segnale KILL per forzarne la chiusura.) -Quando il nuovo processo master si e' chiuso, il vecchio processo -master provvedera' immediatamente ad avviare nuovi processi worker. - - - - - - - - -Se il nuovo processo master termina, allora in vecchio processo master -provvede a cancellare il suffisso .oldbin dal nome del file -contenente l'ID del processo. - - - -Se l'aggiornamento ha successo, al vecchio processo master dovrebbe -essere inviato il segnale QUIT, in maniera che rimangano solo i -processi nuovi: - - PID PPID USER %CPU VSZ WCHAN COMMAND -36264 1 root 0.0 1148 pause nginx: master process /usr/local/nginx/sbin/nginx -36265 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36266 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) -36267 36264 nobody 0.0 1364 kqread nginx: worker process (nginx) - - - - - -
- -
diff --git a/xml/it/docs/debugging_log.xml b/xml/it/docs/debugging_log.xml deleted file mode 100644 --- a/xml/it/docs/debugging_log.xml +++ /dev/null @@ -1,84 +0,0 @@ - - - - -
- - -
- - -Per poter abilitare il log di debug, -nginx deve essere stato configurato appositamente in -fase di compilazione: - - -./configure --with-debug ... - - -Dopo di cio', e' possibile configurare il livello di -debug tramite la direttiva -: - - -error_log /path/to/log debug; - - -La versione binaria di nginx per Windows e' sempre compilata -con tale supporto, per cui in questo caso e' sufficiente -configurare il livello di debug. - - - -Si tenga presente che ridefinire il log senza anche -specificare il livello di debug -causa la disabilitazione del log. -Nell'esempio che segue, la ridefinizione del log nel livello - -disabilita il log di debug per tale server: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log; - ... - -Se ridefinire il log risulta necessario, per non -incorrere in questo problema bisogna indicare -esplicitamente il livello di debug: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log debug; - ... - - - - -E' pure possibile abilitare il debug solo -per -indirizzi client specifici: - - -error_log /path/to/log; - -events { - debug_connection 192.168.1.1; - debug_connection 192.168.10.0/24; -} - - - -
- -
diff --git a/xml/it/docs/events.xml b/xml/it/docs/events.xml deleted file mode 100644 --- a/xml/it/docs/events.xml +++ /dev/null @@ -1,114 +0,0 @@ - - - - -
- -
- - -nginx supporta diversi metodi di processo delle connessioni. -La disponibilita' di un particolare metodo dipende dalla piattaforma usata; -su piattaforme che supportano piu' di un metodo, nginx in genere -e' in grado di selezionare automaticamente il metodo piu' efficiente. -Comunque, se necessario, e' possibile scegliere esplicitamente il metodo -di processo delle connessioni tramite la direttiva -. - - - -I metodi di processo delle connessioni sono i seguenti: - - - - -select—metodo standard. -Il relativo modulo e' compilato automaticamente se la piattaforma non -rende possibile l'uso di metodi piu' efficienti. -E' possibile usare i parametri di configurazione ---with-select_module e ---without-select_module -per abilitare o disabilitare esplicitamente la compilazione di tale modulo. - - - - - -poll—metodo standard. -Il relativo modulo e' compilato automaticamente se la piattaforma non -rende possibile l'uso di metodi piu' efficienti. -E' possibile usare i parametri di configurazione ---with-poll_module e ---without-poll_module -per abilitare o disabilitare esplicitamente la compilazione di tale modulo. - - - - - -kqueue—metodo efficiente usato su -FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0, e Mac OS X. - - - - - -epoll—metodo efficiente usato su -Linux 2.6+. - -Alcune distribuzioni piu' vecchie, ad esempio SuSE 8.2, forniscono -patch che rendono possibile l'uso di questo modulo su kernel 2.4. - - - - - - -rtsig—real time signals, metodo efficiente usato su -Linux 2.2.19+. -Per default, la coda di eventi del sistema e' limitata a 1024 segnali; -su server particolarmente carichi puo' risultare necessario incrementare -tale limite, intervenendo sul parametro del kernel -/proc/sys/kernel/rtsig-max . -Comunque, a partire da Linux 2.6.6-mm2 tale parametro non e' piu' disponibile -e ciascun processo dispone della propria coda di eventi. -La dimensione di ciascuna coda e' definita da RLIMIT_SIGPENDING -e puo' essere modificata tramite il parametro -. - - - -In caso di overflow, nginx scarta del tutto la coda e passa all'uso del -metodo di processo poll sinche' la situazione non -torna normale. - - - - - -/dev/poll—metodo efficiente usato su -Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+, -e Tru64 UNIX 5.1A+. - - - - - -eventport—event ports, metodo efficiente usato su -Solaris 10. - - - - - - -
- -
diff --git a/xml/it/docs/hash.xml b/xml/it/docs/hash.xml deleted file mode 100644 --- a/xml/it/docs/hash.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - -
- -
- - -Per processare rapidamente insiemi di dati, quali ad esempio -nomi di server, valori relativi alla direttiva -, -MIME type, stringhe di nomi di header di richiesta, -nginx usa tabelle di hash. -Durante l'avvio ed in seguito ad ogni rilettura della configurazione, -nginx seleziona la minore dimensione possibile delle tabelle -di hash, tale che la dimensione del bucket che memorizza le chiavi -con identico valore hash non superi il relativo parametro configurato -(hash bucket size). -La dimensione di una tabella e' espressa in bucket; tale dimensione -viene regolata continuamente, sinche' la dimensione non eccede il -valore configurato (hash max size). -Molti hash dispongono di specifiche direttive che consentono la modifica -di tali parametri; ad esempio, per l'hash dei nomi dei server esistono - -e . - - - -Il parametro hash bucket size e' allineato ad una dimensione -multipla di quella di una linea di cache del processore utilizzato; -nei moderni processori cio' riduce il numero di accessi alla memoria -e quindi il tempo necessario a ricercare la chiave di un hash. -Se la dimensione del bucket hash e' pari a quella di una linea di -cache, allora il numero di accessi alla memoria durante la ricerca di -una chiave sara' nel peggiore dei casi pari a due —uno per l'indirizzo -del bucket, l'altro durante la ricerca della chiave nel bucket. -Per tale ragione, se nginx mostra un messaggio che suggerisce -l'incremento o della dimensione massima dell'hash oppure della -dimensione del bucket hash, e' preferibile intervenire anzitutto -sul primo dei due parametri e non modificare per quanto possibile -il secondo. - - -
- -
diff --git a/xml/it/docs/howto_build_on_win32.xml b/xml/it/docs/howto_build_on_win32.xml deleted file mode 100644 --- a/xml/it/docs/howto_build_on_win32.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - - -
- -
- - -Per compilare nginx su piattaforma Microsoft Win32, servono: - - - - -Il compilatore Microsoft Visual C; e' stato verificato che con -Microsoft Visual Studio 8 e 10 è possibile portare -a termine la compilazione. - - - -MSYS. - - - -Perl, se si vuole compilare OpenSSL e nginx con il support SSL; -ad esempio ActivePerl -o Strawberry Perl. - - - -Il client -Mercurial. - - - -Il codice sorgente delle librerie -PCRE, zlib -e OpenSSL. - - - - - -
- -
- - -Prima di iniziare a compilare, assicurarsi che i path alle directory bin di -Perl, Mercurial e MSYS siano stati aggiunti alla variabile d'ambiente PATH. -Per configurare l'ambiente di Visual C, avviare lo script vcvarsall.bat -dalla directory del Visual C. - - - - -Per compilare nginx: - - - -Avviare la bash MSYS. - - - -Fare il check out dei sorgenti nginx dall'archivio hg.nginx.org; ad esempio con: - -hg clone http://hg.nginx.org/nginx - - - - -Creare la directory per la compilazione e la sottodirectory lib, scompattare il -codice sorgente delle librerie zlib, PCRE e OpenSSL in lib: - -mkdir objs -mkdir objs/lib -cd objs/lib -tar -xzf ../../pcre-8.32.tar.gz -tar -xzf ../../zlib-1.2.7.tar.gz -tar -xzf ../../openssl-1.0.1e.tar.gz - - - - -Lanciare lo script 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.32 \ ---with-zlib=objs/lib/zlib-1.2.7 --with-openssl=objs/lib/openssl-1.0.1e \ ---with-select_module --with-http_ssl_module --with-ipv6 - - - - -lanciare make: - -nmake -f objs/Makefile - - - - - - - - -
- -
- - - - - - - - - - - -
-
diff --git a/xml/it/docs/http/configuring_https_servers.xml b/xml/it/docs/http/configuring_https_servers.xml deleted file mode 100644 --- a/xml/it/docs/http/configuring_https_servers.xml +++ /dev/null @@ -1,521 +0,0 @@ - - - - -
- -
- - -Per configurare un server HTTPS, bisogna configurare il parametro -ssl nel -socket in ascolto -del blocco , -e specificare dove sono i file del certificato del server e della relativa -chiave private: - - -server { - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; - ssl_ciphers HIGH:!aNULL:!MD5; - ... -} - - -Il certificato del server e' pubblico: e' inviato a tutti i client che -si connettono al server; la chiave privata al contrario non e' pubblica, -e dovrebbe essere salvata in un file con restrizioni d'accesso, e -comunque non leggibile dal processo master di nginx. -In alternativa, la chiave privata puo' essere salvata nel medesimo file -del certificato: - - - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; - - -pure in questo caso i diritti d'accesso al file dovrebbero essere ristretti. -Anche quando certificato e chiave privata sono salvati entrambi -in un unico file, solo il certificato e' inviato al client. - - - -Le direttive e - possono essere usate -per limitare l'uso alle sole versioni e cifrature forti di SSL/TLS nelle -connessioni. -nginx usa per default “ssl_protocols SSLv3 TLSv1” e -“ssl_ciphers HIGH:!aNULL:!MD5” sin dalla versione 1.0.5, -per cui una configurazione esplicita ha senso solo per le versioni di nginx -piu' vecchie. Dalle versioni 1.1.13 e 1.0.12 nginx usa per default -“ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2”. - - - -La modalita' di cifratura CBC e' potenzialmente vulnerabile ad una serie -di attacchi, in particolare ad un attacco BEST (vedi -CVE-2011-3389). -La configurazione della cifratura puo' essere modificata in maniera da -utilizzare RC4-SHA: - - - ssl_ciphers RC4:HIGH:!aNULL:!MD5; - ssl_prefer_server_ciphers on; - - - -
- - -
- - -Le operazioni SSL utilizzano pesantemente la CPU. Su sistemi -multiprocessore e' bene avviare processi worker in numero almeno pari a -quello dei core. -L'operazione piu' gravosa per la CPU e' l'handshake SSL. -Ci sono due modi per minimizzare il numero di tali operazioni per client: -il primo consiste nell'abilitare connessioni keepalive per inviare diverse -richieste tramite un'unica connessione; il secondo prevede di riutilizzare -i parametri della sessione SSL in maniera tale da evitare l'handshake SSL -per connessioni parallele e susseguenti. -Le sessioni sono salvate in una cache di sessione SSL, condivisa fra i -worker e configurata dalla direttiva -. - -Un megabyte di cache contiene circa 4000 sessioni. Il timeout di default della -cache e' di 5 minuti; puo' essere aumentato intervenendo sulla direttiva -. -Segue una configurazione di esempio ottimizzata per un sistema multicore con -10 megabyte di cache di sessione condivisa: - - -worker_processes auto; - -http { - ssl_session_cache shared:SSL:10m; - ssl_session_timeout 10m; - - server { - listen 443 ssl; - server_name www.example.com; - keepalive_timeout 70; - - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; - ssl_ciphers HIGH:!aNULL:!MD5; - ... - - - -
- - -
- - -Capita talvolta che alcuni certificati server firmati da autorita' di -certificazione ben note siano tranquillamente accettati da alcuni browser, -ma mostrino invece problemi con altri. Cio' succede quando' l'autorita' -emittente ha firmato il certificato usandone uno intermedio che non e' -presente nell'elenco delle autorita' di certificazione distribuito con -uno specifico browser. -In tal caso l'autorita' fornisce un gruppo di certificati che dovrebbero -essere concatenati al certificato server firmato. -Il certificato server deve comparire prima dei certificati concatenati -nel file risultante: - - -$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt - - -Il file che ne deriva va usato con la direttiva -: - - -server { - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.chained.crt; - ssl_certificate_key www.example.com.key; - ... -} - - -Se il certificato server ed il gruppo di certificati sono stati concatenati -nell'ordine sbagliato, nginx non riuscira' a partire e mostrera' il -seguente messaggio di errore: - - -SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed - (SSL: error:0B080074:x509 certificate routines: - X509_check_private_key:key values mismatch) - - -dato che nginx ha tentato di usare la chiave privata non con il certificato -server ma con il primo certificato del gruppo. - - - -Di solito i browser salvano i certificati intermedi che ricevono se sono -firmati da autorita' di certificazione riconosciute, per cui browser molto -usati potrebbero gia' avere i certificati intermedi richiesti, e quindi -non avere problemi anche quando ricevono un certificato privo della -relativa concatenazione di certificati. -Comunque, per assicurare che il server invii la concatenazione di certificati -completa, e' possibile usare da linea di comando il programma -openssl, ad esempio: - - -$ 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/CN=www.GoDaddy.com - /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=ValiCert, Inc. - /OU=ValiCert Class 2 Policy Validation Authority - /CN=http://www.valicert.com//emailAddress=info@valicert.com -... - - -In questo esempio, il soggetto (“s”, vale a dire "subject") -del certificato server #0 www.GoDaddy.com e' firmato da -un emittente (“i”, vale a dire "issuer") che a sua volta e' -il soggetto del certificato #1, il quale e' firmato da un emittente che e' -il soggetto del certificato #2, che e' finalmente firmato dalla autorita' -di certificazione ben nota ValiCert, Inc., il cui certificato e' -presente nella base dati precaricata del browser -("che al mercato mio padre compro'"). - - - -Se il gruppo di certificati non fosse stato aggiunto, sarebbe stato -visualizzato il solo certificato #0. - - -
- - -
- - -E' possibile configurare un singolo server che tratti sia richieste HTTP, -sia richieste HTTPS: - - -server { - listen 80; - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ... -} - - - -Prima della versione 0.7.14, SSL non poteva essere abilitato -selettivamente per singoli socket in ascolto, come nell'esempio -precedente: SSL poteva solo essere abilitato per l'intero server, -usando la direttiva , -e rendendo quindi impossibile la configurazione di un server -unico per HTTP e HTTPS. -Il parametro ssl della direttiva - e' stato aggiunto -per risolvere questo problema. L'uso della direttiva - -e' pertanto sconsigliato nelle versioni recenti. - - - -
- - -
- - -Quando si configurano due o piu' server HTTPS in ascolto su un singolo -indirizzo IP, sorge spesso un problema: - - -server { - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 443 ssl; - server_name www.example.org; - ssl_certificate www.example.org.crt; - ... -} - - -Con questa configurazione un browser riceve il certificato del server di default, -vale a dire www.example.com, indipendentemente da quale sia -il nome del server richiesto. Cio' e' causato dal comportamento del protocollo -SSL: la connessione SSL si stabilisce prima che il browser invii una richiesta -HTTP, percio' quando nginx ancora non sa quale sara' il nome del server richiesto; -per tale ragione, non puo' fare altro che offrire il certificato del server di default. - - - -Il metodo classico per risolvere questo problema consiste nell'assegnare -un indirizzo IP distinto a ciascun server HTTPS: - - -server { - listen 192.168.1.1:443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 192.168.1.2:443 ssl; - server_name www.example.org; - ssl_certificate www.example.org.crt; - ... -} - - - - -
- - -Ci sono altre maniere tramite cui condividere un singolo indirizzo IP -fra molti server HTTPS, tutte comunque non prive di problemi. -Ad esempio, e' possibile usare un certificato con diversi nomi di server -nel campo SubjectAltName, per esempio -www.example.com and www.example.org, -tuttavia la lunghezza del campo SubjectAltName e' limitata. - - - -Un'altra tecnica prevede l'uso di un certificato il cui nome e' definito con -caratteri jolly, per esempio *.example.org. -Un certificato con caratteri jolly va bene per tutti i sottodomini del -dominio specificato, ma per un solo livello: in questo caso ad esempio -verra' riconosciuta corrispondenza con www.example.org, -ma non con example.org e www.sub.example.org. -I due metodi mostrati possono essere combinati: nel campo SubjectAltName -un certificato puo' contenere sia nomi esatti sia nomi con caratteri jolly, -ad esempio example.org e *.example.org. - - - -Nel caso in cui si usi un certificato con nomi multipli, e' bene -indicare la posizione del relativo file e della chiave nel livello -http della configurazione, in maniera da avere una singola -copia in memoria da far ereditare a tutti i server: - - -ssl_certificate common.crt; -ssl_certificate_key common.key; - -server { - listen 443 ssl; - server_name www.example.com; - ... -} - -server { - listen 443 ssl; - server_name www.example.org; - ... -} - - - -
- - -
- - -Una soluzione piu' generale per l'uso di server HTTPS multipli su un singolo -indirizzo IP e' data dalla -estensione -TLS Server Name Indication (SNI, RFC 6066), che consente ad un -browser di indicare il nome del server richiesto durante l'handshake SSL e, -percio', permette al server di sapere quale certificato dovrebbe essere -usato durante la connessione. Purtroppo, SNI ha un supporto piuttosto -limitato nei browser; al momento e' supportato a partire dalle seguenti -versioni: - - - - - - -Opera 8.0; - - - -MSIE 7.0 (ma solo su Windows Vista o superiore); - - - -Firefox 2.0 e altri browser che usano Mozilla Platform rv:1.8.1; - - - -Safari 3.2.1 (la versione per Windows supporta SNI su Vista o superiore); - - - -Chrome (la versione per Windows supporta SNI su Vista o superiore). - - - - -Con SNI e' possibile passare solo nomi di dominio, tuttavia alcuni browser -potrebbero erroneamente consentire di passare come nome anche l'indirizzo -IP del server. -E' bene comunque non fare affidamento su questo comportamento. - - - - -Per poter usare SNI in nginx, e' necessario che sia supportato sia nella -libreria OpenSSL con cui il binario e' stato compilato, sia nella -libreria a cui e' linkato dinamicamente in esecuzione. -OpenSSL supporta SNI sin dalla versione 0.9.8f, a patto che sia stata -compilata con l'opzione di configurazione “--enable-tlsext”; -dalla versione 0.9.8j tale opzione e' abilitata per default. -Se nginx e' compilato con il supporto a SNI, allora l'esecuzione con -il parametro “-V” mostra: - - -$ nginx -V -... -TLS SNI support enabled -... - - -Di contro, se nginx e' stato compilato con il supporto a SNI, ma la libreria -OpenSSL a cui e' linkato dinamicamente ne e' priva, viene mostrato: - - -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 - - - -
- -
- - -
- - - - - -Il parametro “-V” mostra lo stato del supporto a SNI -dalla versione 0.8.21 e 0.7.62 in poi. - - - -Il parametro ssl della direttiva - -e' supportato -dalla versione 0.7.14 in poi; -prima della versione 0.8.21 poteva essere specificato solo -insieme al parametro default. - - - -SNI e' supportato -dalla versione 0.5.32 in poi. - - - -La cache condivisa di sessione SSL e' supportata -dalla versione 0.5.6 in poi. - - - - - - - - - -Versioni 0.7.65, 0.8.19 e successive: i protocolli SSL default sono SSLv2, TLSv1, -e TLSv1.2 (se supportati dalla libreria OpenSSL). - - - -Versioni 0.7.64, 0.8.18 e precedenti: i protocolli SSL default sono SSLv2, -SSLv3, e TLSv1. - - - - - - - - - -Versioni 1.0.5 e successive: i sistemi di cifratura SSL default sono -“HIGH:!aNULL:!MD5”. - - - -Versioni 0.7.65, 0.8.20 e successive: i sistemi di cifratura SSL default sono -“HIGH:!ADH:!MD5”. - - - -Versione 0.8.19: i sistemi di cifratura SSL default sono -“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”. - - - -Versioni 0.7.64, 0.8.18 e precedenti: i sistemi di cifratura SSL default sono
-“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”. - - - - - - -
- - -
diff --git a/xml/it/docs/http/converting_rewrite_rules.xml b/xml/it/docs/http/converting_rewrite_rules.xml deleted file mode 100644 --- a/xml/it/docs/http/converting_rewrite_rules.xml +++ /dev/null @@ -1,159 +0,0 @@ - - - - -
- - -
- - -Chi, nel corso della propria esperienza con host condivisi, e' sempre -stato abituato a configurare tutto usando solo i file -.htaccess di Apache, in genere converte le seguenti regole: - - -RewriteCond %{HTTP_HOST} example.org -RewriteRule (.*) http://www.example.org$1 - - -in qualcosa tipo: - - -server { - listen 80; - server_name www.example.org example.org; - if ($http_host = example.org) { - rewrite (.*) http://www.example.org$1; - } - ... -} - - - - -Si tratta di una soluzione errata, poco elegante e inefficiente. -La soluzione corretta prevede la definizione di un server distinto per -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; - ... -} - - - -Nelle versioni antecedenti la 0.9.1, i redirect possono essere definiti con: - - rewrite ^ http://www.example.org$request_uri?; - - - - - -
- - -
- - -Un altro esempio: -invece della logica “upside-down”, vale a dire “tutto quello -che non e' example.com ne' www.example.com”: - - -RewriteCond %{HTTP_HOST} !example.com -RewriteCond %{HTTP_HOST} !www.example.com -RewriteRule (.*) http://www.example.com$1 - - -e' meglio semplicemente definire -example.com, www.example.com, -e “tutto il resto”: - - -server { - listen 80; - server_name example.com www.example.com; - ... -} - -server { - listen 80 default_server; - server_name _; - return 301 http://example.com$request_uri; -} - - - -Nelle versioni antecedenti la 0.9.1, i redirect possono essere definiti con: - - rewrite ^ http://example.com$request_uri?; - - - - - -
- - -
- - -Regole di Mongrel tipiche, quali: - - -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] - - -andrebbero convertite in: - - -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; -} - - - -
- -
diff --git a/xml/it/docs/http/request_processing.xml b/xml/it/docs/http/request_processing.xml deleted file mode 100644 --- a/xml/it/docs/http/request_processing.xml +++ /dev/null @@ -1,302 +0,0 @@ - - - - -
- -
- - -La prima cosa che nginx fa e' decidere quale server deve -processare la richiesta. Si consideri una semplice configurazione -in cui tutti i tre server virtuali sono in ascolto sulla porta *:80 : - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name example.net www.example.net; - ... -} - -server { - listen 80; - server_name example.com www.example.com; - ... -} - - - - - -In questa configurazione nginx verifica solo il campo
Host
-dell'header di richiesta, per determinare a quale server la richiesta debba -essere assegnata. -Se il suo valore non corrisponde con quello di alcun nome di server, -oppure se la richiesta semplicemente non contiene tale campo dell'header, -allora nginx assegna la richiesta al server di default per la relativa porta. -Nella configurazione precedente, il server di default e' il primo—si -tratta del comportamento standard di nginx. -E' anche possibile indicare esplicitamente il server di default, tramite il -parametro default_server nella direttiva - : - -server { - listen 80 default_server; - server_name example.net www.example.net; - ... -} - - - -Il parametro default_server e' disponibile a partire dalla -versione 0.8.21 di nginx. -Nelle versioni precedenti bisogna usare invece il parametro -default. - -Si noti che il server di default e' una proprieta' della porta in ascolto, -e non del nome del server; l'argomento sara' ripreso in seguito. - - -
- - -
- - -Se si desidera che le richieste prive dell'header
Host
-non siano processate, e' possibile definire un server che si limita a scartarle: - -server { - listen 80; - server_name ""; - return 444; -} - -In questo caso il nome del server e' definito con una stringa vuota, -la quale corrispondera' a tutte le richieste prive del campo -
Host
dell'header; per chiudere la connessione nginx -restituisce il codice 444 (non standard). - -A partire dalla versione 0.8.48 quella descritta e' la configurazione -default per i nomi di server, per cui e' possibile omettere -server_name "". -Nelle versioni precedenti, come nome del server di default si utilizzava -l'hostname della macchina. - - - -
- - -
- - -Una configurazione piu' complessa prevede vari server virtuali -in ascolto su indirizzi differenti: - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80; - server_name example.com www.example.com; - ... -} - -In tale configurazione nginx dapprima confronta l'indirizzo IP -e la porta della richiesta con le direttive - dei blocchi -; -quindi, per ciascun blocco per cui c'e' corrispondenza, nginx confronta -il campo
Host
dell'header della richiesta con i -valori del blocco. -Se il nome del server non e' presente in alcun blocco, la richiesta -viene processata dal server di default. -Ad esempio, una richiesta per www.example.com -ricevuta sulla porta 192.168.1.1:80, sara' processata dal server di -default di 192.168.1.1:80, vale a dire dal primo server, in quanto non -c'e' alcun nome www.example.com definito per tale -combinazione di indirizzo e porta. - - - -Si precisa nuovamente che il server di default e' una proprieta' di -indirizzo e porta in ascolto, e che e' possibile definire server di -default differenti per combinazioni differenti di indirizzo e porta: - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80 default_server; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80 default_server; - server_name example.com www.example.com; - ... -} - - - - -
- - -
- - -Nel seguito si analizza come nginx scelga la location per -processare una richiesta nel caso di un tipico, semplice sito PHP: - -server { - listen 80; - server_name example.org www.example.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; - } -} - - - - - -Per prima cosa nginx individua fra tutte le location definite da una -stringa quella con il prefisso specifico piu' lungo (l'ordine con cui -sono elencate non e' rilevante); nella configurazione precedente il -solo prefisso definito e' “/”, che trova -corrispondenza in qualsiasi richiesta e che quindi verra' comunque -preso in considerazione, come ultima risorsa. -Successivamente, nginx analizza le location definite tramite una -espressione regolare, fermandosi appena ne individua una che -corrisponde (in questo caso l'ordine in cui sono inserite nel file -di configurazione e' rilevante in quanto nginx parte dalla prima e le -analizza una dopo l'altra). La prima location individuata fra quelle -definite come espressione regolare e' quella prescelta; se non ce n'e' -nessuna, nginx ripiega su quella individuata al passo precedente tramite -il prefisso. - - - - -Notare che tutti i tipi di location sono confrontati con il solo URI -della linea di richiesta, senza argomenti; -cio' e' dovuto al fatto che gli argomenti nella stringa di richiesta -possono essere inviati in vari modi, ad esempio: - -/index.php?user=john&page=1 -/index.php?page=1&user=john - -Inoltre, nella stringa di richiesta e' possibile scrivere qualsiasi cosa: - -/index.php?page=1&something+else&user=john - - - - - -Seguono alcuni esempi di processo di richieste in base alla -configurazione precedente: - - - -Una richiesta “/logo.gif” corrisponde al prefisso -di location “/”, ma anche all'espressione regolare -“\.(gif|jpg|png)$”, per cui si utilizzera' quest'ultima -corrispondenza in quanto, come spiegato in precedenza, le espressioni -regolari hanno sempre priorita' sulle stringhe fisse. -Usando la direttiva “root /data/www” la richiesta -e' mappata sul file /data/www/logo.gif , che quindi e' inviato -al client. - - - -Una richiesta “/index.php” corrisponde sia al prefisso -“/” sia all'espressione regolare -“\.(php)$”, per cui sara' processata da quest'ultima -sezione della configurazione, e la richiesta sara' inoltrata al server -FastCGI in ascolto su localhost:9000. -La direttiva - -imposta il parametro FastCGI -SCRIPT_FILENAME a “/data/www/index.php”, -ed il server FastCGI esegue il file. -La variabile $document_root contiene il valore della direttiva -, e la variabile -$fastcgi_script_name il valore della richiesta URI, vale a dire -“/index.php”. - - - -Una richiesta “/about.html” corrisponde al solo prefisso -“/”, per cui sara' processata da questa sezione. -La direttiva “root /data/www” mappa la richiesta sul file -/data/www/about.html, che e' inviato al client. - - - -Una richiesta “/” e' processata in maniera piuttosto -complessa. Corrisponde al solo prefisso “/”, per cui e' -processata dalla relativa sezione; la direttiva -, -in accordo ai propri parametri e alla direttiva -“root /data/www”, verifica la presenza di eventuali file index. -Se il file /data/www/index.html non esiste, ma esiste invece il -file /data/www/index.php , allora la direttiva esegue una -redirezione interna su “/index.php”, e nginx ricerca -nuovamente le location, come se si trattasse di una richiesta del client. -Come visto in precedenza, alla fine la richiesta rediretta e' processata -dal server FastCGI. - - - - - - -
- -
diff --git a/xml/it/docs/http/server_names.xml b/xml/it/docs/http/server_names.xml deleted file mode 100644 --- a/xml/it/docs/http/server_names.xml +++ /dev/null @@ -1,513 +0,0 @@ - - - - -
- - -
- - -I nomi dei server, definiti usando la direttiva -, -determinano quale blocco - -viene usato per una data richiesta (per approfondire vedi -"”). - -I nomi possono essere definiti tramite una stringa determinata, -oppure con caratteri jolly, oppure ancora tramite espressioni regolari: - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name *.example.org; - ... -} - -server { - listen 80; - server_name mail.*; - ... -} - -server { - listen 80; - server_name ~^(?<user>.+)\.example\.net$; - ... -} - - - - -Nel corso della ricerca di un server virtuale name-based, se il nome corrisponde -a piu' di una delle definizioni, ad esempio sia a nomi definiti tramite -caratteri jolly che a nomi definiti tramite espressioni regolari, verra' scelta -la prima variante individuata, secondo il seguente ordine di precedenza decrescente: - - - -nome esatto - - - -fra quelli definiti con caratteri jolly, il piu' lungo nome che comincia per -asterisco, ad esempio “*.example.org” - - - -fra quelli definiti con caratteri jolly, il piu' lungo nome che termina per -asterisco, ad esempio “mail.*” - - - -fra quelli definiti come espressioni regolare, il primo corrispondente -(in base all'ordine con cui compaiono nel file di configurazione) - - - - - -
- - -
- - -Un nome con caratteri jolly puo' contenere un asterisco solo all'inizio -o alla fine del nome, e solo accanto ad un punto; ad esempio, i nomi -“www.*.example.org” -e “w*.example.org” non sono validi (pero' e' -possibile definirli tramite espressioni regolari, per esempio in questo -caso “~^www\..+\.example\.org$” e -“~^w.*\.example\.org$”). -Un asterisco puo' corrispondere a piu' parti di un nome: -“*.example.org” corrisponde non solo a -www.example.org ma anche a -www.sub.example.org. - - - -E' possibile definire un nome speciale nella forma -“.example.org”, che corrisponde sia al nome esatto -“example.org” sia al nome con caratteri jolly -“*.example.org”. - - -
- - -
- - -Le espressioni regolari usate da nginx sono compatibili con quelle usate -dal linguaggio di programmazione Perl (PCRE). -Per usare una espressione regolare, il nome del server deve iniziare con -il carattere tilde: - - -server_name ~^www\d+\.example\.net$; - - -altrimenti viene considerato e trattato come un nome esatto, oppure, -se l'espressione contiene un asterisco, come un nome con caratteri jolly -(e molto probabilmente come uno non valido). -E' importante non dimenticare i caratteri ancora “^” e -“$”: non sono necessari dal punto di vista sintattico, -ma lo sono da quello logico. -Si noti inoltre che i caratteri punto nei nomi di dominio sono definiti -facendoli precedere da “\”. -Una espressione regolare contenente i caratteri “{” e -“}”, deve essere racchiusa fra doppi apici: - - -server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; - - -altrimenti nginx non sara' in grado di avviarsi e mostrera' l'errore: - - -directive "server_name" is not terminated by ";" in ... - - -La sezione catturata di una espressione regolare che definisce un nome -puo' essere usata in seguito come una variabile: - - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - - -La libreria PCRE supporta sezioni catturate di nomi tramite la seguente sintassi: - - - - - - - - - - - - - - - - - - -
?<nome>Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi
?'nome'Sintassi compatibile con Perl 5.10, supportata da PCRE-7.0 in poi
?P<nome>Sintassi compatibile con Python, supportata da PCRE-4.0 in poi
- -Quando nginx non riesce ad avviarsi e mostra il seguente messaggio d'errore: - - -pcre_compile() failed: unrecognized character after (?< in ... - - -significa che la libreria PCRE e' troppo vecchia, per cui e' bene provare -ad usare invece la sintassi: -“?P<name>”. -E' possibile riferirsi a sezioni catturate anche usando cifre: - - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - - -Comunque, tale uso dovrebbe essere limitato ai casi piu' semplici (come -ad esempio quello appena mostrato), dato che i riferimenti con cifra -possono essere sovrascritti facilmente. - - - -
- - -
- - -Alcuni nomi di server sono trattati in maniera speciale. - - - -Se si desidera che le richieste prive del campo
Host
-dell'header siano processato in un blocco - -che non e' quello di default, e' necessario specificare un nome vuoto: - - -server { - listen 80; - server_name example.org www.example.org ""; - ... -} - - - - - -Se in un blocco -non e' specificato alcun , -allora nginx usa il nome vuoto come nome del server. - -sino alla versione 0.8.48, in questi casi nginx usava l'hostname della -macchina come nome del server. - - - - -Se il nome del server e' definito come “$hostname” (0.9.4), -il nome del server effettivamente usato e' l'hostname della macchina. - - - -Se viene fatta una richiesta usando l'indirizzo IP invece di un nome di server, -il campo
Host
dell'header di richiesta conterra' l'indirizzo IP, -e la richiesta potra' essere processata usando l'indirizzo IP come nome del server: - - -server { - listen 80; - server_name example.org - www.example.org - "" - 192.168.1.1 - ; - ... -} - - - - -In molti esempi di configurazione di un server catch-all e' spesso possibile -notare l'uso di uno strano nome -“_”: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -Tale nome non ha niente di speciale, si tratta di un nome qualsiasi, -scelto piu' o meno a caso fra quelli non validi come nome di dominio. -Altri esempi di nomi non validi che sono talvolta pure usati sono -“--” e “!@#”. - - - -Sino alla versione 0.6.25 nginx supportava il nome speciale -“*”, che e' stato spesso interpretato erroneamente -come un nome, non valido, per un server catch-all. -In effetti, non si e' mai trattato di un nome per un server catch-all o -di un nome con caratteri jolly: piuttosto, serviva a fornire la funzionalita' -attualmente affidata alla direttiva -. -Il nome speciale “*” e' attualmente sconsigliato, -ed e' considerato preferibile l'uso della direttiva -. -Si noti che non c'e' alcun modo di specificare un nome catch-all o un -server di default usando la direttiva -: -si tratta di una proprieta' della direttiva - -e non della direttiva - -Si faccia riferimento anche a -“”. -E' possibile definire server in ascolto sulle porte *:80 e *:8080, -e specificare che uno e' quello di default per la porta *:8080, -mentre l'altro e' quello di default per la porta *:80: - - -server { - listen 80; - listen 8080 default_server; - server_name example.net; - ... -} - -server { - listen 80 default_server; - listen 8080; - server_name example.org; - ... -} - - - - -
- - -
- - -I nomi esatti, i nomi con caratteri jolly che iniziano per asterisco, -ed i nomi con caratteri jolly che terminano per asterisco, -sono registrati in tre tabelle di hash collegate alle porte in ascolto. -Le dimensioni delle tabelle sono ottimizzate in fase di configurazione, -in maniera tale che i nomi possano essere recuperati con il minimo numero -di miss alla cache della CPU. -Dettagli su come configurare le tabelle di hash sono forniti in un -documento apposito. - - - -La prima tabella di hash consultata e' quella dei nomi esatti; -se non si trova il nome ricercato, si prosegue nella tabella di hash -dei nomi con caratteri jolly che iniziano per asterisco; -in caso di ulteriore riscontro negativo, si passa alla tabella di hash -dei nomi con caratteri jolly che finiscono per asterisco. - - - -La ricerca in una tabella di hash per nomi con caratteri jolly e' piu' lenta -della ricerca nella tabella relativa ai nomi esatti, dato che i nomi sono ricercati -per parti del dominio. -Si noti che il formato speciale “.example.org” e' salvato in una -tabella di hash di nomi con caratteri jolly, e non in quella dei nomi esatti. - - - -Le espressioni regolari sono testate in sequenza, per cui sono il metodo piu' -lento e sono non scalabili. - - - -Per queste ragioni, se possibile e' sempre meglio usare nomi esatti. -Ad esempio, se i nomi di server richiesti piu' di frequente sono -example.org e www.example.org, -e' piu' efficiente definirli in maniera esplicita: - - -server { - listen 80; - server_name example.org www.example.org *.example.org; - ... -} - - -che usare il formato piu' semplice: - - -server { - listen 80; - server_name .example.org; - ... -} - - - - -Se il numero di nomi di server definiti e' molto grande, -oppure se sono stati definiti nomi di server decisamente lunghi, -per la messa a punto e' possibile che sia necessario utilizzare -le direttive del livello http - -e . -Il valore di default della direttiva - -puo' essere pari a 32 o 64, oppure ad un altro valore, in base alla -dimensione della linea di cache della CPU. -Se il valore di default e' 32 ed il nome del server e' definito come -“too.long.server.name.example.org”, allora nginx non potra' -partire e sara' mostrato il seguente messaggio d'errore: - - -could not build the server_names_hash, -you should increase server_names_hash_bucket_size: 32 - - -In tal caso, il valore della direttiva dovrebbe essere aumentata sino alla -successiva potenza di due: - - -http { - server_names_hash_bucket_size 64; - ... - - -Se sono stati definiti molti nomi di server, potrebbe comparire un altro -messaggio di errore: - - -could not build the server_names_hash, -you should increase either server_names_hash_max_size: 512 -or server_names_hash_bucket_size: 32 - - -In tal caso, si provi prima a impostare - -ad un numero prossimo al numero dei nomi di server. -Solo nel caso in cui cio' non risultasse sufficiente, oppure se il tempo di avvio -di nginx fosse inaccetabilmente alto, si provi ad incrementare -. - - - -Se su una data porta in ascolto c'e' un unico server, allora nginx saltera' del tutto -la verifica dei nomi dei server (e non costituira' le tabelle di hash per la porta -in questione). -C'e' una eccezione: se un nome di server e' una espressione regolare con -sezioni catturate, allora nginx dovra' svolgere l'espressione regolare per recuperare -le sezioni catturate. - - -
- - -
- - - - - -Il nome di server speciale “$hostname” e' supportato -dalla versione 0.9.4 in poi. - - - -Il nome vuoto “” e' il valore di default per il nome dei server -dalla versione 0.8.48 in poi. - - - -Il riferimento tramite nome a sezioni catturate in un nome di server definito -tramite espressione regolare e' supportato dalla versione 0.8.25 in poi. - - - -Le sezioni catturate in un nome di server definito tramite espressione regolare -sono supportate dalla versione 0.7.40 in poi. - - - -Il nome di server vuoto “” e' supportato -dalla versione 0.7.12 in poi. - - - -La definizione di nomi di server e di espressioni regolari tramite caratteri jolly -e' supportata dalla versione 0.6.25 in poi. - - - -La definizione di nomi di server tramite espressioni regolari e' supportata -dalla versione 0.6.7 in poi. - - - -Il formato con caratteri jolly example.* e' supportato -dalla versione 0.6.0 in poi. - - - -Il formato speciale .example.org e' supportato -dalla versione 0.3.18 in poi. - - - -Il formato con caratteri jolly *.example.org e' supportato -dalla versione 0.1.13 in poi. - - - - - -
- -
diff --git a/xml/it/docs/index.xml b/xml/it/docs/index.xml deleted file mode 100644 --- a/xml/it/docs/index.xml +++ /dev/null @@ -1,402 +0,0 @@ - - - - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - -
- - - - -
diff --git a/xml/it/docs/install.xml b/xml/it/docs/install.xml deleted file mode 100644 --- a/xml/it/docs/install.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - -
- -
- - -nginx puo' essere installato in varie maniere, a seconda del sistema operativo. - - -
- - -
- - -Con Linux, e' possibile usare i pacchetti nginx binari, scaricabili da nginx.org. - - -
- - -
- - -Con FreeBSD, e' possibile installare nginx o tramite -pacchetti -binari oppure tramite ports. -Ports consente maggiore flessibilita', e permette di scegliere fra un gran numero di opzioni: -ports provvedera' a compilare nginx con le opzioni specificate, e ad installarlo. - - -
- - -
- - -Se e' richiesta qualche funzionalita' particolare e non disponibile con i pacchetti binari o con ports, -e' possibile compilare nginx a partire dai sorgenti. Per quanto maggiormente flessibile, -questo approccio per un principiante puo' risultare piu' complesso. -Per maggiori informazioni, fare riferimento a . - - -
- -
diff --git a/xml/it/docs/syntax.xml b/xml/it/docs/syntax.xml deleted file mode 100644 --- a/xml/it/docs/syntax.xml +++ /dev/null @@ -1,54 +0,0 @@ - - - - -
- -
- - -Le dimensioni possono essere indicate in byte, kilobyte -(suffissi k e K), e megabyte -(suffissi m e M), ad esempio -“1024”, “8k”, “1m”. - - - -Gli intervalli di tempo possono essere specificati in millisecondi, -secondi, minuti, ore, giorni, e cosi' via, utilizzando i suffissi seguenti: - - - - - - - - - -
msmillisecondi
ssecondi
mminuti
hore
dgiorni
wsettimane
Mmesi, 30 giorni
yanni, 365 giorni
- - - -E' possibile combinare in un singolo valore piu' unita', specificandole -dalla piu' significativa alla meno significativa ed eventualmente -separandole con spazi. Ad esempio, “1h 30m” indica -lo stesso tempo di “90m” o “5400s”. -Un valore senza suffisso indica secondi, comunque e' sempre raccomandato -specificare un suffisso. - - - -Alcuni intervalli temporali possono essere specificati solo -con una risoluzione di secondi. - - -
- -
diff --git a/xml/it/docs/windows.xml b/xml/it/docs/windows.xml deleted file mode 100644 --- a/xml/it/docs/windows.xml +++ /dev/null @@ -1,158 +0,0 @@ - - - - -
- -
- - -La versione di nginx per Windows usa le API native Win32, e non il layer di -emulazione Cygwin. -Attualmente e' usato solo il metodo di connessione select, -per cui non e' possibile attendersi prestazioni e scalabilita' eccellenti; -per tale ragione, e anche per altre, quella per Windows e' -considerata una versione beta. -Al momento risultano implementate piu' o meno le stesse funzionalita' della -versione di nginx per UNIX, con l'eccezione del filtro XSLT, del filtro immagini, -del modulo GeoIP, e del linguaggio Perl embedded. - - - -Per installare nginx/Windows, e' bene scaricare -l'ultima distribuzione disponibile della versione mainline (), -che contiene le correzioni piu' recenti. -Bisogna scompattare la distribuzione, spostarsi nella directory -nginx- e lanciare nginx. -Segue un esempio in cui la directory e' sul drive C: : - - -cd c:\ -unzip nginx-.zip -cd nginx- -start nginx - - -Avviare l'utility a linea di comando tasklist -per vedere i processi nginx: - - -C:\nginx->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 - - -Uno dei due e' il processo master, l'altro il processo worker. -Se nginx non si avvia, verificarne la ragione nel file di log -degli errori logs\error.log ; -se tale file non e' stato creato, la ragione dovrebbe essere riportata -nel Windows Event Log. -Se viene mostrata una pagina di errore invece della pagina attesa, -verificarne la ragione nel solito file logs\error.log . - - - -nginx/Windows utilizza la directory in cui e' stato avviato come prefisso -per i path relativi della configurazione. -Nell'esempio precedente, il prefisso e' -C:\nginx-\ . -I path nei file di configurazione devono essere specificati usando gli -slash del formato UNIX: - - -access_log logs/site.log; -root C:/web/html; - - - - -nginx/Windows e' eseguito come una normale applicazione di console e -non come un servizio, e puo' essere gestito con i comandi seguenti: - - - - - - - - - - - - - - - - - - - - - - - -
nginx -s stoparresto rapido
nginx -s quitarresto controllato
nginx -s reload -ricaricamento della configurazione, -con avvio di un nuovo processo worker con la nuova configurazione, -ed arresto controllato del vecchio processo worker. -
nginx -s reopenriapertura dei file di log
- - -
- -
- - - - -Nonostante sia possibile avviare diversi worker, in effetti -solo uno di essi esegue tutto il lavoro. - - - -Un worker puo' gestire non piu' di 1024 connessioni simultanee. - - - -La cache, ed altri moduli che richiedono il supporto alla memoria condivisa, -non funzionano su Windows Vista e versioni successive, in quanto su tali -versioni e' in uso la address space layout randomization. - - - - -
- -
- - - - -L'esecuzione come servizio. - - - -L'uso di I/O completion port come metodo di processo delle connessioni. - - - -L'uso di piu' thread worker all'interno di un singolo processo worker. - - - - -
- -
diff --git a/xml/it/download.xml b/xml/it/download.xml deleted file mode 100644 --- a/xml/it/download.xml +++ /dev/null @@ -1,79 +0,0 @@ - - - - -
- - -
- - - -
- - -
- - - -
- - -
- - - -
- - -
- - -Archivio Mercurial (sola lettura): - - - -code: http://hg.nginx.org/nginx - - -site: http://hg.nginx.org/nginx.org - - - - - - -Esplora i sorgenti con Trac - - -
- - -
- - - - - -Pacchetti Linux per la -versione stabile - - - -Pacchetti Linux per la -versione principale - - - - - -
- -
diff --git a/xml/it/index.xml b/xml/it/index.xml deleted file mode 100644 --- a/xml/it/index.xml +++ /dev/null @@ -1,357 +0,0 @@ - - - - -
- - -
- - -nginx [engine x] e' un server HTTP e reverse proxy, -nonche' un server mail proxy, scritto da -Igor Sysoev. -Per molto tempo e' stato usato principalmente per alcuni -siti russi ad alto carico, ad esempio -Yandex, -Mail.Ru, -VKontakte e -Rambler; -in base ai dati di Netcraft, nell'ottobre 2013 nginx -e' il server HTTP o reverse proxy del -15.08% -dei siti a maggiore carico. -Alcuni casi di successo sono: -Netflix, -Wordpress.com, -FastMail.FM. - - - -La documentazione ed i sorgenti sono distribuiti in base alla -licenza BSD con 2 clausole. - - -
- - -
- - - - - -Servizio di file statici e -index, -autoindexing; -cache dei descrittori dei file aperti; - - - -Reverse proxy accelerato -con cache; -semplice bilanciamento -di carico e load balancing; - - - -Supporto accelerato con cache di server -FastCGI, -uwsgi, SCGI, e -memcached; -semplice bilanciamento -di carico e load balancing; - - - -Architettura modulare. -Filtri per -gzip, -intervalli di byte, risposte a blocchi, -XSLT, -SSI, -e filtro per la -trasformazione d'immagini. -Inclusioni multiple di SSI in una stessa pagina possono essere -processate in parallelo se sono gestite da server proxy o FastCGI; - - - -Supporto a SSL e TLS SNI -. - - - - - -
- - -
- - - - - -server virtuali -name-based e IP-based; - - - -Supporto a connessioni -keep-alive -e pipelined; - - - -Configurazione flessibile; - - - -Caricamento di una nuova -configurazione e -aggiornamento dell'eseguibile senza interruzione di servizio ai client; - - - -Access log in vari -formati, log con buffer -, e veloce rotazione dei log; - - - -Redirezione -dei codici d'errore 3xx-5xx; - - - -Modulo di rewrite: -trasformazione delle URI -con uso di espressioni regolari; - - - -Esecuzione di funzioni differenti - a seconda dell' -indirizzo del client; - - - -Controllo d'accesso in base a -indirizzo IP del client, a - -password (HTTP Basic authentication), e al -risultato di una sottorichiesta; - - - -Validazione del -referer HTTP; - - - -Metodi PUT, DELETE, MKCOL, COPY, -e MOVE; - - - -Streaming -FLV e -MP4; - - - - -Limitazione della velocita' del flusso di risposta; - - - -Limitazione del numero di -connessioni o -richieste -simultanee da un dato indirizzo; - - - -Perl embedded. - - - - - -
- - -
- - - - - -Redirezione dell'utente verso server -IMAP -o -POP3 -tramite un server esterno di -autenticazione -HTTP; - - - -Autenticazione dell'utente tramite un server esterno di -autenticazione -e redirezione della connessione verso un server -SMTP; - - - -Metodi di autenticazione: - - - - -POP3: -USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -IMAP: -LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -SMTP: -AUTH LOGIN/PLAIN/CRAM-MD5; - - - - - - -supporto a -SSL; - - - -supporto a -STARTTLS -e STLS. - - - - - -
- - -
- - - - - -Un processo master e numerosi processi worker; -i processi worker girano con un utente non privilegiato; - - - -Supporto a -kqueue (FreeBSD 4.1+), -epoll (Linux 2.6+), segnali rt (Linux 2.2.19+), -/dev/poll (Solaris 7 11/99+), event ports (Solaris 10), -select, e poll; - - - -Supporto alle differenti funzionalita' di kqueue, fra cui EV_CLEAR, EV_DISABLE -(per disabilitare temporaneamente eventi), NOTE_LOWAT, EV_EOF, -numero di dati disponibili, codici d'errore; - - - -supporto a sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5+), sendfile64 (Linux 2.4.21+), -e sendfilev (Solaris 8 7/01+); - - - -File AIO -(FreeBSD 4.3+, Linux 2.6.22+); - - - -DIRECTIO -(FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, Mac OS X); - - - -supporto a -Accept-filters (FreeBSD 4.1+, NetBSD 5.0+) e TCP_DEFER_ACCEPT (Linux 2.4+); - - - -10000 connessioni HTTP keep-alive inattive richiedono circa 2.5M di memoria; - - - -Le operazioni di copia di dati risultano minime. - - - - - -
- - -
- - - - - -FreeBSD 3—10 / i386; FreeBSD 5—10 / amd64; - - - -Linux 2.2—3 / i386; Linux 2.6—3 / amd64; - - - -Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; - - - -AIX 7.1 / powerpc; - - - -HP-UX 11.31 / ia64; - - - -Mac OS X / ppc, i386; - - - -Windows XP, Windows Server 2003. - - - - - -
- -
diff --git a/xml/it/linux_packages.xml b/xml/it/linux_packages.xml deleted file mode 100644 --- a/xml/it/linux_packages.xml +++ /dev/null @@ -1,332 +0,0 @@ - - - - -
- -
- - -Attualmente sono disponibili pacchetti nginx per le seguenti distribuzioni -e versioni: - - - -RHEL/CentOS: - - - - - - - - - - - - - - - -
Versione
5.x
6.x
- - - -Debian: - - - - - - - - - - - - - - - - - - -
VersioneNome in codice
6.xsqueeze
7.xwheezy
- - - -Ubuntu: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VersioneNome in codice
10.04lucid
11.10oneiric
12.04precise
12.10quantal
13.04raring
- - - -Per abilitare gli aggiornamenti automatici dei pacchetti Linux, -per la distribuzione RHEL/CentOS configurare l'archivio yum, -e per la distribuzione Debian/Ubuntu l'archivio apt. - - -
- - -
- - -Nel caso di RHEL/CentOS, per configurare l'archivio yum scegliere -l'opportuno pacchetto nginx-release dalla lista: - - - - -RHEL 5 - - - -RHEL 6 - - - -CentOS 5 - - - -CentOS 6 - - - - -Questo pacchetto contiene il file di configurazione di yum ed una chiave -PGP pubblica necessaria per autenticare i pacchetti RPM firmati. -Bisogna scaricarlo e installarlo, e quindi lanciare il seguente comando: - -yum install nginx - - -In alternativa, la configurazione di un archivio puo' essere aggiunta -a mano, quindi senza installare il relativo pacchetto -nginx-release. Bisogna creare il file -/etc/yum.repos.d/nginx.repo con il contenuto seguente: - - -[nginx] -name=nginx repo -baseurl=http://nginx.org/packages/OS/OSRELEASE/$basearch/ -gpgcheck=0 -enabled=1 - - -Sostituire “OS” con “rhel” o -“centos”, -a seconda della distribuzione usata, e “OSRELEASE” -con “5” o “6”, -per le versioni 5.x o 6.x, rispettivamente. - - - -Nel caso di Debian/Ubuntu, per autenticare la firma dell'archivio nginx -e per eliminare gli avvisi riguardanti l'assenza della chiave PGP che -vengono visualizzati durante l'installazione dei pacchetti di nginx, -bisogna aggiungere la chiave usata per firmare i pacchetti e l'archivio -nginx al keyring del programma apt; a tal proposito -bisogna scaricare -questa chiave, ed aggiungerla al keyring di apt -tramite il seguente comando: - -sudo apt-key add nginx_signing.key - - - - -Per Debian, bisogna sostituire nome_in_codice con il -nome in codice della distribuzione, e -aggiungere in coda al file /etc/apt/sources.list le righe seguenti: - - -deb http://nginx.org/packages/debian/ nome_in_codice nginx -deb-src http://nginx.org/packages/debian/ nome_in_codice nginx - - - - -Per Ubuntu, bisogna sostituire nome_in_codice con il -nome in codice della distribuzione, e -aggiungere in coda al file /etc/apt/sources.list le righe seguenti: - - -deb http://nginx.org/packages/ubuntu/ nome_in_codice nginx -deb-src http://nginx.org/packages/ubuntu/ nome_in_codice nginx - - - - -Sia per Debian, sia per Ubuntu, lanciare infine i seguenti comandi: - -apt-get update -apt-get install nginx - - - -
- - -
- - -Nel caso di RHEL/CentOS, per configurare l'archivio yum creare il file -/etc/yum.repos.d/nginx.repo -con il contenuto seguente: - - -[nginx] -name=nginx repo -baseurl=http://nginx.org/packages/mainline/OS/OSRELEASE/$basearch/ -gpgcheck=0 -enabled=1 - - -Sostituire “OS” con “rhel” o -“centos”, -a seconda della distribuzione usata, e “OSRELEASE” -con “5” o “6”, -per le versioni 5.x o 6.x, rispettivamente. - - - -Nel caso di Debian/Ubuntu, per autenticare la firma dell'archivio nginx -e per eliminare gli avvisi riguardanti l'assenza della chiave PGP che -vengono visualizzati durante l'installazione dei pacchetti di nginx, -bisogna aggiungere la chiave usata per firmare i pacchetti e l'archivio -nginx al keyring del programma apt; a tal proposito -bisogna scaricare -questa chiave, ed aggiungerla al keyring di apt -tramite il seguente comando: - -sudo apt-key add nginx_signing.key - - - - -Per Debian, bisogna sostituire nome_in_codice con il -nome in codice della distribuzione, e -aggiungere in coda al file /etc/apt/sources.list le righe seguenti: - - -deb http://nginx.org/packages/mainline/debian/ nome_in_codice nginx -deb-src http://nginx.org/packages/mainline/debian/ nome_in_codice nginx - - - - -Per Ubuntu, bisogna sostituire nome_in_codice con il -nome in codice della distribuzione, e -aggiungere in coda al file /etc/apt/sources.list le righe seguenti: - - -deb http://nginx.org/packages/mainline/ubuntu/ nome_in_codice nginx -deb-src http://nginx.org/packages/mainline/ubuntu/ nome_in_codice nginx - - - - -Sia per Debian, sia per Ubuntu, lanciare infine i seguenti comandi: - -apt-get update -apt-get install nginx - - - -
- - -
- - -I pacchetti RPM e gli archivi Debian/Ubuntu usano firme digitali per -verificare l'integrita' e l'origine dei pacchetti scaricati. -Per verificare la firma bisogna scaricare la -chiave di firma di nginx -e importarla nel keyring del programma rpm o apt: - - - - -In Debian/Ubuntu: -sudo apt-key add nginx_signing.key - - - -In RHEL/CentOS: -sudo rpm --import nginx_signing.key - - - - - - -In Debian/Ubuntu le firme sono verificate per default, -invece in RHEL/CentOS e' necessario porre -gpgcheck=1 nel file -/etc/yum.repos.d/nginx.repo. - - - -Essendo tutti su un medesimo server, le nostre -chiavi PGP e i -pacchetti sono egualmente affidabili; e' comunque caldamente -consigliato verificare l'autenticita' delle chiavi PGP scaricate. -PGP ha il concetto di "rete di fiducia", con cui si intende -che una chiave e' firmata dalla chiave di qualcun altro, -che a sua volta e' firmata da un'altra chiave, e cosi' via; -grazie a cio' e' spesso possibile costruire una catena ininterrotta -da una chiave arbitraria alla chiave di qualcun altro che e' -conosciuto ed e' considerato affidabile, riuscendo quindi a stabilire -l'affidabilita' della prima chiave della catena. -Tale concetto e' descritto in dettaglio nel - -GPG Mini Howto. -Le nostre chiavi hanno firme sufficienti a rendere relativamente -semplice la verifica dell'autenticita'. - - -
- -
diff --git a/xml/it/support.xml b/xml/it/support.xml deleted file mode 100644 --- a/xml/it/support.xml +++ /dev/null @@ -1,87 +0,0 @@ - - - - -
- - -
- - -Le mailing list possono essere -consultate -liberamente; -per postare sulle mailing list e' prima necessario -iscrivere -l'indirizzo e-mail che sara' usato negli invii. - - - - - - -Mailing list in inglese -nginx@nginx.org, - -archivio, - -archivio Gmane, - -archivio MARC - - - -Mailing list in russo -nginx-ru@nginx.org, - -archivio, - -archivio Gmane - - - - - -
- - -
- - - - - -Mailing list per sviluppatori (in inglese) -nginx-devel@nginx.org, - -archivio - - - - -Consulta il codice sorgente - - - - -Segnala un bug - - - - -Come contribuire - - - - - -
- -
diff --git a/xml/ja/GNUmakefile b/xml/ja/GNUmakefile deleted file mode 100644 --- a/xml/ja/GNUmakefile +++ /dev/null @@ -1,10 +0,0 @@ -DOCS = \ - faq \ - http/request_processing \ - http/server_names \ - http/configuring_https_servers \ - debugging_log \ - http/converting_rewrite_rules \ - -FAQ = \ - sys_errlist \ diff --git a/xml/ja/docs/debugging_log.xml b/xml/ja/docs/debugging_log.xml deleted file mode 100644 --- a/xml/ja/docs/debugging_log.xml +++ /dev/null @@ -1,61 +0,0 @@ - - -
- -
- - -デバッギングログを有効にするには、nginx をデバッグオプションを付けて設定する必要があります: - - -./configure --with-debug ... - - -次に error_log の debug レベルをセットします: - - -error_log /path/to/log debug; - - -nginx の Windows バイナリバージョンでは常にデバッグログモードがサポートされてビルドされているので、debug レベルをセットするだけです。 - - - -別のレベル、例えば server レベルでログを定義するとそのサーバでのデバッギングログが無効になりますので注意してください: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log; - ... - -このサーバログをコメントアウトするか debug フラグを追加してください: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log debug; - ... - - - - -また、特定のアドレスだけデバッギングログを有効にすることもできます: - - -error_log /path/to/log; - -events { - debug_connection 192.168.1.1; - debug_connection 192.168.10.0/24; -} - - - -
- -
diff --git a/xml/ja/docs/faq.xml b/xml/ja/docs/faq.xml deleted file mode 100644 --- a/xml/ja/docs/faq.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -
- -
- - - - - - - - - - - -
- -
diff --git a/xml/ja/docs/http/configuring_https_servers.xml b/xml/ja/docs/http/configuring_https_servers.xml deleted file mode 100644 --- a/xml/ja/docs/http/configuring_https_servers.xml +++ /dev/null @@ -1,373 +0,0 @@ - - -
- -
- - -HTTPS サーバを設定するには server ブロックで SSL プロトコルを有効にして、サーバ証明書ファイルと秘密鍵ファイルの場所を指定する必要があります: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1; - ssl_ciphers HIGH:!ADH:!MD5; - ... -} - - -サーバ証明書とはドメインの所有者情報や、送信情報の暗号化に必要な公開鍵を含む電子証明書です。そのサーバに接続するすべてのクライアントに送られます。秘密鍵はサーバ証明書に含まれる公開鍵で暗号化された情報を復号するために必要な鍵で、秘匿する必要が有ります。アクセスを制限したファイルに保存するようにしてください。ただし、nginx のマスタープロセスからは読めるようにする必要があります。もうひとつの方法として、秘密鍵は証明書と同じファイルに保存することもできます: - - - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; - - -この場合もファイルのアクセス権は制限するようにします。証明書と秘密鍵がひとつのファイルに保存されていても、証明書だけがクライアントに送られます。 - - - -SSL プロトコルの強力なバージョンと暗号に接続を制限するには、ディレクティブ ssl_protocols と ssl_ciphers を使用します。バージョン 0.8.20 以降、nginx は ssl_protocols SSLv3 TLSv1 と ssl_ciphers HIGH:!ADH:!MD5 をデフォルトとして使用しているので、これより古い nginx のバージョンでのみ設定してください。 - - -
- - -
- - -SSL の工程は CPU リソースを余計に消費します。マルチプロセッサシステムでは（利用できる CPU コアの数よりも大きい数の）複数のワーカープロセスを走らせるといいでしょう。最も CPU に負荷がかかる工程は SSL ハンドシェイクです。クライアント毎のこの工程数を最小化するには２つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、ssl_session_cache ディレクティブで設定されています。１メガバイトのキャッシュには約４０００のセッションが含まれます。キャッシュのデフォルトタイムアウトは５分です。この値は ssl_session_timeout ディレクティブを使用して増やすことができます。次の例は１０Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です: - - - -worker_processes 4; - -http { - ssl_session_cache shared:SSL:10m; - ssl_session_timeout 10m; - - server { - listen 443; - server_name www.example.com; - keepalive_timeout 70; - - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1; - ssl_ciphers HIGH:!ADH:!MD5; - ... - - - -
- - -
- - -ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります: - - -$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt - - -この結合されたファイルを ssl_certificate ディレクティブで使われるようにします: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.chained.crt; - ssl_certificate_key www.example.com.key; - ... -} - - -サーバ証明書とバンドルされたものが間違った順序で連結されていた場合、nginx は起動に失敗して次のエラーメッセージを表示します: - - -SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed - (SSL: error:0B080074:x509 certificate routines: - X509_check_private_key:key values mismatch) - - -これは、nginx がサーバ証明書ではなくバンドルされた最初の証明書で秘密鍵を使おうとするからです。 - - - -ブラウザは通常、信頼されている認証局によって署名されている受信した中間証明書を保存します。したがって、よく使われているブラウザは要求された中間証明書をすでに保持しているかもしれませんし、連鎖バンドルなしで送られた証明書にエラーを出すかもしれません。サーバに完全な連鎖証明書を送信させるには openssl コマンドラインユーティリティを使うといいでしょう。例えば: - - -$ 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/CN=www.GoDaddy.com - /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=ValiCert, Inc. - /OU=ValiCert Class 2 Policy Validation Authority - /CN=http://www.valicert.com//emailAddress=info@valicert.com -... - - -この例では、www.GoDaddy.com サーバ証明書 #0 の対象 (“s”) はそれ自身が証明書 #1 の対象である発行者 (“i”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である ValiCert, Inc. によって署名されていて、ValiCert, Inc. の証明書はブラウザに組み込まれている証明書ベースに保持されています（こうして連鎖します）。 - - - -もし証明書バンドルを追加していなければ、サーバ証明書 #0 しか見れません。 - - -
- - -
- - -最初の段階から HTTP と HTTPS プロトコル用にサーバを分けて設定するのは優れた実践です。現時点では両者の機能性としては等しいかもしれませんが、将来的に大きな変更があるかもしれず、統合されたサーバの使用が問題になるかもしれません。とはいえ、HTTP と HTTPS のサーバが等しく、将来のことを考えたくないのなら、ディレクティブ ssl on を削除して *:443 ポートに ssl パラメータを追加することによって HTTP と HTTPS リクエストの両者を扱う単一のサーバを設定することができます: - - -server { - listen 80; - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ... -} - - - -0.8.21 以前では、nginx は default パラメータで待ち受けているソケットに ssl パラメータをセットすることしかできませんでした: - -listen 443 default ssl; - - - - -
- - -
- - -単一の IP アドレスを２つ以上の HTTPS サーバで待ち受けるように設定するとよく発生する問題があります: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - -この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは www.example.com の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 - - - -この問題を解決するもっとも古くてもっとも堅実な方法は、各 HTTPS サーバに別個の IP アドレスを割り当てることです: - - -server { - listen 192.168.1.1:443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 192.168.1.2:443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - - -
- - -
- - -単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、www.example.com と www.example.org）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 - - - -もうひとつの方法は、例えば *.example.org のようにワイルドカード名を持った証明書を使用する方法です。この証明書は www.example.org にマッチしますが example.org や www.sub.example.org にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば example.org と *.example.org のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 - - - -すべてのサーバでひとつのメモリーコピーを継承するためには、複数サーバ名を持つ証明書ファイルとその秘密鍵ファイルを設定の http レベルに置くとよいでしょう: - - -ssl_certificate common.crt; -ssl_certificate_key common.key; - -server { - listen 443; - server_name www.example.com; - ssl on; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ... -} - - - -
- - -
- - -単一の IP アドレス上で複数の HTTPS サーバを動かすときのさらに包括的な解決方法として TLSv1.1 Server Name Indication extension（サーバ名指示拡張） (SNI, RFC3546) があります。これは、ブラウザが SSL ハンドシェイクの間にリクエストされたサーバ名を渡せるようにするもので、それによりサーバはその接続でどの証明書を使用するべきかが分かります。しかし、SNI は限られたブラウザしかサポートしていません。現時点では次のブラウザのバージョン以降のものがサポートされています: - - - - - -Opera 8.0 - - - -MSIE 7.0 (Windows Vista 以降のみ) - - - -Firefox 2.0 および Mozilla Platform rv:1.8.1 を使用している他のブラウザ - - - -Safari 3.2.1 (Windows バージョンでは Vista 以降) - - - -Chrome (Windows バージョンでは Vista 以降) - - - - - -nginx で SNI を使用するためには、nginx バイナリがビルドされたときの OpenSSL ライブラリとランタイムで動的にリンクされるライブラリの両方でサポートされていることが必要です。OpenSSL は設定オプション “--enable-tlsext”. でビルドされていれば、バージョン 0.9.8f 以降で SNI をサポートしています。OpenSSL 0.9.8j 以降ではこのオプションはデフォルトで有効になっています。nginx が SNI サポート付きでビルドされていれば、“-V” スイッチとともに起動すると nginx が次のように表示します: - - -$ nginx -V -... -TLS SNI support enabled -... - - -しかし、SNI が有効になっている nginx が SNI サポート無しの OpenSSL ライブラリに動的にリンクされている場合、nginx は次の警告を表示します: - - -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 - - - -
- - -
- - - - - -“-V” スイッチでの SNI サポートステータス表示は 0.8.21 以降と 0.7.62 でサポートされています。 - - - -listen ディレクティブの ssl パラメータは 0.7.14 以降からサポートされています。 - - - -SNI は 0.5.32 以降からサポートされています。 - - - -共有 SSL セッションキャッシュは 0.5.6 以降からサポートされています。 - - - - - - - - - -バージョン 0.7.65 と 0.8.19 以降のデフォルトの SSL プロトコルは SSLv3 と TLSv1 です。 - - - -バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL プロトコルは SSLv2、SSLv3、TLSv1 です。 - - - - - - - - - -バージョン 0.7.65 と 0.8.20 以降のデフォルトの SSL 暗号は HIGH:!ADH:!MD5 です。 - - - -バージョン 0.8.19 のデフォルトの SSL 暗号は ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM です。 - - - -バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL 暗号は ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP です。 - - - - - - -
- - -
diff --git a/xml/ja/docs/http/converting_rewrite_rules.xml b/xml/ja/docs/http/converting_rewrite_rules.xml deleted file mode 100644 --- a/xml/ja/docs/http/converting_rewrite_rules.xml +++ /dev/null @@ -1,128 +0,0 @@ - - -
- -
- - -共有のホスティングで 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; - rewrite ^ http://www.example.org$request_uri?; -} - -server { - listen 80; - server_name www.example.org; - ... -} - - - -
- - -
- - -別の例として、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.org www.example.org; - ... -} - -server { - listen 80 default_server; - server_name _; - rewrite ^ http://example.org$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/index.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; -} - - - -
- -
diff --git a/xml/ja/docs/http/request_processing.xml b/xml/ja/docs/http/request_processing.xml deleted file mode 100644 --- a/xml/ja/docs/http/request_processing.xml +++ /dev/null @@ -1,217 +0,0 @@ - - -
- -
- - -nginx はまず最初にどのサーバがそのリクエストを処理すべきなのかを決定します。手はじめに、３つすべての仮想サーバが port *:80 で待ち受けている単純な設定から見てみましょう: - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name example.net www.example.net; - ... -} - -server { - listen 80; - server_name example.com www.example.com; - ... -} - - - - -この設定では nginx は、（ブラウザからの）HTTP リクエストの “Host” ヘッダだけを考査して、そのリクエストをどのサーバに振り向けるべきかを決定します。もし “Host” ヘッダがどのサーバ名ともマッチしない場合、またはリクエストにこのフィールドがまったく含まれていない場合は、nginxはこのリクエストをデフォルトサーバに振り向けます。上記の設定ではデフォルトサーバは最初のもので、これは nginx の標準的なデフォルトの挙動です。設定内の最初のサーバをデフォルトサーバにしたくない場合は、listen ディレクティブに default_server パラメータを使って明示的に設定することができます: - - -server { - listen 80 default_server; - server_name example.net www.example.net; - ... -} - - - -この default_server パラメータはバージョン 0.8.21 以上で利用できます。それ以前のバージョンでは代わりに default パラメータを使用してください。 - - -このデフォルトサーバは listen ディレクティブのプロパティで、server_name ディレクティブのプロパティではないことに注意してください。詳細は後述します。 - - -
- - -
- - -“Host” ヘッダが未定義のリクエストを処理させたくない場合は、リクエストを単にドロップさせるデフォルトサーバを設定できます: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -ここでは存在しないドメイン名 “_” をサーバ名として選択し、接続を閉じる nginx の特別な標準外コード 444 を返します。このサーバ用にサーバ名を設定しなければならないことに注意してください。さもなければ nginx はホスト名を使用します。 - - -
- - -
- - -異なるアドレスで待ち受けている仮想サーバのより複雑な設定をみてみましょう: - - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80; - server_name example.com www.example.com; - ... -} - - -この設定では、nginx はまず最初に server ブロックの listen ディレクティブに対してリクエストの IP アドレスとポートを考査します。次に、その IP アドレスとポートにマッチする server ブロックの server_name ディレクティブに対して、その HTTP リクエストの “Host” ヘッダを考査します。 - -もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、192.168.1.1:80 ポートで受信された www.example.com へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは www.example.com は定義されていないからです。 - - - -すでに述べたように、デフォルトサーバは listen ディレクティブのプロパティで、別の listen ディレクティブには別のデフォルトサーバが定義されています: - - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80 default_server; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80 default_server; - server_name example.com www.example.com; - ... -} - - - -
- - -
- - -では、典型的で単純な PHP サイトで nginx がどのようにロケーション（location）を選択してリクエストを処理するのかを見てみましょう: - - -server { - listen 80; - server_name example.org www.example.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; - } -} - - - - -nginx はまず最初に、リストの順序には関係なくリテラルな文字列によって指定されているもっとも限定されたロケーションを検索します。上記の設定では唯一のリテラルなロケーションは / であり、したがってどのリクエストでもマッチして最終的にこのロケーションが使われます。次に nginx は、設定ファイルにリストされている順番で正規表現によって指定されているロケーションをチェックします。最初にマッチした正規表現で検索はストップし、 nginx そのロケーションを使用します。もしどの正規表現もリクエストにマッチしない場合は、nginx はその前に見つかったもっとも限定されたリテラルなロケーションを使用します。 - - - -すべてのタイプのロケーションはクエリー部分を除いたリクエスト URI 部分のみを考査することに注意してください。これはクエリー文字列の引数がいろいろな方法で渡されることがあるためです。例えば: - - -/index.php?user=john&page=1 -/index.php?page=1&user=john - - -さらに、クエリー文字列ではどのようなリクエストでも可能だからです: - - -/index.php?page=1&something+else&user=john - - - - -では、上記の設定ではどのようにリクエストが処理されるのかを見てみましょう: - - - - - -リクエスト /logo.gif はリテラルなロケーション / に最初にマッチし、次に正規表現 \.(gif|jpg|png)$ にマッチするので、後者のロケーションによって処理されます。 このリクエストは root /data/www ディレクティブを使用してファイル /data/www/logo.gif にマップされ、このファイルがクライアントに送られます。 - - - - - -リクエスト /index.php もまたリテラルなロケーション / に最初にマッチし、次に正規表現 \.(php)$ にマッチします。したがって、このリクエストは後者のロケーションによって処理され、localhost:9000 で待ち受けている FastCGI サーバに渡されます。fastcgi_param ディレクティブは FastCGI のパラメータ SCRIPT_FILENAME を /data/www/index.php にセットし、この FastCGI サーバがこのファイルを実行します。変数 $document_root は root ディレクティブの値と同等で、変数 $fastcgi_script_name はリクエスト URI、例えば /index.php と同等です。 - - - - - -リクエスト /about.html はリテラルなロケーション / のみにマッチします。したがってこのロケーションで処理されます。このリクエストは root ディレクティブのパラメータ /data/www を使い、ファイル /data/www/about.html にマップされ、クライアントに送られます。 - - - - - -リクエスト / の処理はより複雑です。これはリテラルなロケーション / のみにマッチし、このロケーションで処理されます。ついで index ディレクティブがパラメータと root ディレクティブのパラメータ /data/www にしたがって index ファイルが存在するかどうかを考査します。もし /data/www/index.php ファイル存在すればこのディレクティブは /index.php への内部リダイレクトを実行し、nginx はまるでこのリクエストがクライアントに送られたかのようにこのロケーションを再び検索します。先に見たように、リダイレクトされたリクエストは最終的に FastCGI サーバで処理されます。 - - - - - - -
- -
diff --git a/xml/ja/docs/http/server_names.xml b/xml/ja/docs/http/server_names.xml deleted file mode 100644 --- a/xml/ja/docs/http/server_names.xml +++ /dev/null @@ -1,350 +0,0 @@ - - -
- -
- - -サーバ名は server_name ディレクティブを使用して定義され、リクエストに対してどのサーバブロックが使われるかを決定します。「」もお読みください。これらは完全一致名、ワイルドカード名、正規表現で定義されます: - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name *.example.org; - ... -} - -server { - listen 80; - server_name mail.*; - ... -} - -server { - listen 80; - server_name ~^(?<user>.+)\.example\.net$; - ... -} - - -サーバ名は次の順序で考査されます: - - - - -完全一致名 - - - -アスタリスクで始まるワイルドカード名: *.example.org - - - -アスタリスクで終わるワイルドカード名: mail.* - - - -設定ファイル内の順序での正規表現 - - - -最初にマッチしたところで検索は終了します。. - - -
- - -
- - -ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 www.*.example.org や w*.example.org は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば ~^www\..+\.example\.org$ や ~^w.*\.example\.org$ として指定することができます。アスタリスクは複数部分にマッチさせることができます。*.example.org は www.example.org だけでなく www.sub.example.org にもマッチします。 - - - -特別なワイルドカードの形式 .example.org は、完全一致名 example.org とワイルドカード名 *.example.org の両方にマッチさせるように利用できます。 - - -
- - -
- - -nginx で使用される正規表現は Perl プログラミング言語（PCRE）で使用されているものと互換性があります。正規表現を使用するには、サーバ名を必ずチルダで始めます: - - -server_name ~^www\d+\.example\.net$; - - -チルダで始まっていないと完全一致名として、またはその正規表現にアスタリスクが含まれている場合はワイルドカード名として（そしてたいていの場合は無効なものとして）扱われてしまいます。“^” と “$” アンカーをセットし忘れないようにしてください。これらは構文的には必須ではありませんが論理的に必須です。また、ドメイン名のドットはバックスラッシュで必ずエスケープしてください。“{” と “}” 文字を含む正規表現は必ずダブルクォーテーションで囲ってください: - - -server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; - - -さもないと、nginx は起動に失敗し次のエラーメッセージを表示します: - - -directive "server_name" is not terminated by ";" in ... - - -正規表現の名前付きキャプチャは変数としてその後で使用されます: - - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - - -PCRE ライブラリは次の構文を使用した名前付きキャプチャをサポートしています: - - - - - - - - - - - - - - - - - - -
?<name>Perl 5.10 互換構文、PCRE-7.0 よりサポート
?'name'Perl 5.10 互換構文、PCRE-7.0 よりサポート
?P<name>Python 互換構文、PCRE-4.0よりサポート
- -nginx が起動に失敗すると次のエラーメッセージを表示します: - - -pcre_compile() failed: unrecognized character after (?< in ... - - -これは PCRE ライブラリが古いので ?P<name> 構文を試すように、という意味です。このキャプチャは数字形式でも使用できます: - - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - - -とはいえ、数字形式は簡単に上書きすることができるため、このような使用法は（上記のような）単純なケースに限るべきです。 - - - -
- - -
- - -デフォルトではないサーバブロックで “Host” ヘッダ無しのリクエストを処理させたい場合は、空のサーバ名を指定します: - - -server { - listen 80; - server_name example.org www.example.org ""; - ... -} - - - - -server_name がサーバブロックで定義されていない場合は、nginx はサーバ名として空の名前を使用します。 - - - - -nginx のバージョン 0.8.48 までは、このような場合はサーバ名としてホスト名を使用していました。 - - - -サーバ名ではなく IP アドレスを使用したリクエストが送られてきた場合、そのリクエストの “Host” ヘッダには IP アドレスが含まれているので、その IP アドレスをサーバ名として利用してそのリクエストを処理できます: - - -server { - listen 80; - server_name example.org - www.example.org - "" - 192.168.1.1 - ; - ... -} - - - - -すべてのサーバに適合させる例では奇妙なサーバ名 “_” が使われます: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -このサーバ名に特別なところはありません。単にどのサーバ名とも決してマッチしない無数の無効なドメイン名のひとつです。したがって、 “--”、“!@#” なども同様な結果を得られます。 - - - -nginx バージョン 0.6.25 までは特別なサーバ名 “*” をサポートしていて、これは誤ってすべてのサーバ名と一致するもの（キャッチオール名）として解釈されていました。この特別なサーバ名 “*”はキャッチオールまたはワイルドカードとして機能したことはありませんでした。代わりに、今は server_name_in_redirect ディレクティブによって提供されている機能の役を果たしていました。特別なサーバ名 “*” は今後廃止予定ですので、server_name_in_redirect ディレクティブを使うようにしてください。キャッチオール名を指定したり server_name ディレクティブを使用したデフォルトサーバを指定したりする方法はないことに注意してください。これは listen ディレクティブのプロパティであり、server_name ディレクティブのプロパティではありません。“” も参照してください。 -ポート *:80 と *:8080 で待ち受けているサーバを定義し、ひとつをポート *:8080 のデフォルトサーバへ、もうひとつをポート *:80 のデフォルトサーバへ振り向けることができます。 - - -server { - listen 80; - listen 8080 default_server; - server_name example.net; - ... -} - -server { - listen 80 default_server; - listen 8080; - server_name example.org; - ... -} - - - - -
- - -
- - -完全一致名とワイルドカード名はハッシュで保存されます。このハッシュは待ち受けポートに結び付けられ、各待ち受けポートは、完全一致名のハッシュ、アスタリスクで始まるワイルドカード名のハッシュ、アスタリスクで終わるワイルドカード名のハッシュの３つまでのハッシュを持つことができます。ハッシュのサイズは構成フェーズで最適化されるので、CPU キャッシュのミスは最低でもサーバ名を見つけることができます。最初に完全一致名のハッシュが検索されます。完全一致名のハッシュを使って見つからなければ、次にアスタリスクで始まるワイルドカード名のハッシュが検索されます。さらにまだ見つからなければ、アスタリスクで終わるワイルドカード名のハッシュが検索されます。ワイルドカード名のハッシュの検索は完全一致名のハッシュの検索よりも遅くなります。これはサーバ名の検索がドメイン部分によって検索されるからです。特別なワイルドカード形式の .example.org は完全一致名のハッシュではなくワイルドカード名のハッシュで保存されます。正規表現は順番に考査されるので、これがもっとも遅い方式ですし、非スケーラブルでもあります。 - - - -これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が example.org と www.example.org だとすると、これらを明示的に定義するとより効率的です: - - -server { - listen 80; - server_name example.org www.example.org *.example.org; - ... -} - - -上記は次の単純化された形式を使用するよりも効率的です: - - -server { - listen 80; - server_name .example.org; - ... -} - - - - -たくさんの数のサーバ名を定義したり非常に長いサーバ名を定義したりする場合は、http レベルの server_names_hash_max_size と server_names_hash_bucket_size ディレクティブを調整する必要があるかもしれません。server_names_hash_bucket_size のデフォルト値は 32、もしくは 64、あるいはお使いの CPU キャッシュラインのサイズによってはその他の値になっているかもしれません。もしデフォルト値が 32 でサーバ名として “too.long.server.name.example.org” のような非常に長いサーバ名を定義している場合、nginx は起動に失敗し、次のエラーメッセージを表示させます: - - -could not build the server_names_hash, -you should increase server_names_hash_bucket_size: 32 - - -この場合、このディレクティブの値を次の 2 の累乗にセットします: - - -http { - server_names_hash_bucket_size 64; - ... - - -非常にたくさんの数のサーバ名を定義した場合は次のエラーメッセージが表示されます: - - -could not build the server_names_hash, -you should increase either server_names_hash_max_size: 512 -or server_names_hash_bucket_size: 32 - - -まず最初に server_names_hash_max_size の値を、定義するサーバ名の数に近い数に設定して試します。この設定がうまくいかない時だけ、もしくは nginx の起動時間が許容できないほど長い場合だけ server_names_hash_bucket_size の値を増やしてみます。 - - - -待ち受けているポートがひとつだけでサーバもひとつだけの場合、nginx はサーバ名を考査しません（また、待ち受けポート用のハッシュも生成しません）。しかし一つ例外があります。server_name がキャプチャを伴った正規表現の場合、nginx はキャプチャを取得するためにこの正規表現を実行します。 - - -
- - -
- - - - - -0.8.48 以降、デフォルトのサーバ名の値は空の名前 “” です。 - - - -正規表現サーバ名の名前付きキャプチャのサポートは 0.8.25 からです。 - - - -正規表現サーバ名のキャプチャのサポートは 0.7.40 からです。 - - - -空のサーバ名 “” のサポートは 0.7.12 からです。 - - - -ワイルドカードサーバ名と正規表現の最初のサーバ名としての使用は0.6.25 からサポートされています。 - - - -正規表現サーバ名のサポートは 0.6.7 からです。 - - - -ワイルドカードの形式 example.* のサポートは 0.6.0 からです。 - - - -特別な形式 .example.org のサポートは 0.3.18 からです。 - - - -ワイルドカードの形式 *.example.org のサポートは 0.1.13 からです。 - - - - - -
- -
diff --git a/xml/ja/docs/index.xml b/xml/ja/docs/index.xml deleted file mode 100644 --- a/xml/ja/docs/index.xml +++ /dev/null @@ -1,50 +0,0 @@ - - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - -
- -
diff --git a/xml/ja/docs/sys_errlist.xml b/xml/ja/docs/sys_errlist.xml deleted file mode 100644 --- a/xml/ja/docs/sys_errlist.xml +++ /dev/null @@ -1,27 +0,0 @@ - - -
- -
- - -nginx のバージョン 0.7.66、0.8.35、もしくはそれ以上を Linux でビルド中、次の警告メッセージが出ます: - - -warning: `sys_errlist' is deprecated; - use `strerror' or `strerror_r' instead -warning: `sys_nerr' is deprecated; - use `strerror' or `strerror_r' instead - - -これは正常です。strerror() と strerror_r() 関数が非同期シグナルセーフではないので、nginx はシングルハンドラの中で非推奨の sys_errlist[] と sys_nerr を使う必要があります。 - - -
- -
diff --git a/xml/ja/index.xml b/xml/ja/index.xml deleted file mode 100644 --- a/xml/ja/index.xml +++ /dev/null @@ -1,243 +0,0 @@ - - -
- - -
- - -nginx [えんじんえっくす] は Igor Sysoev によって作られた HTTP とリバースプロキシのサーバで、メールプロキシサーバでもあります。Rambler -(RamblerMedia.com) を含むロシアの多くの高負荷サイトで５年以上も動いています。Netcraft によると、nginx は 2010 年 4 月時点で 4.70% の人気サイトでサーバーとして、もしくはプロキシとして利用されています。成功例としては FastMail.FM や -Wordpress.com があります。 - - - -ソースコードは BSD 風の 2 箇条ライセンスでライセンスされています。 - - -
- - -
- - - - - -スタティックなインデックスファイルの提供、自動インデクシング、オープンなファイルディスクリプタキャッシュ - - - -キャッシングで高速化されたリバースプロキシ、シンプルなロードバランシングとフォールトトレランス - - - -リモートの FastCGI サーバのキャッシングによる高速化サポート、シンプルなロードバランシングとフォールトトレランス - - - -モジュールアーキテクチャ。フィルタには gzip、バイトレンジ、チャンク化されたレスポンス、XSLT、SSI、画像リサイズフィルタが含まれます。FastCGI もしくはプロキシ化されたサーバなら、単一ページ内への複数 SSI 封入が並列で処理可能。 - - - -SSL と TLS SNI サポート。 - - - - - -
- - -
- - - - - -名前ベースと IP ベースの仮想サーバ - - - -キープアライブとパイプライン接続のサポート - - - -柔軟な設定 - - - -クライアント処理を中断させること無く再構成、オンラインアップグレード - - - -アクセスログフォーマット、バッファされたログ書き込み、素早いログローテーション - - - -3xx-5xx エラーコードのリダイレクト - - - -rewrite モジュール - - - -クライアントの IP アドレスをベースにしたアクセスコントロールと HTTP ベーシック認証 - - - -PUT、DELETE、MKCOL、COPY、MOVE メソッド - - - -FLV ストリーミング - - - -速度制限 - - - -同一アドレスからの同時接続もしくは同時リクエストの制限 - - - -埋め込み perl - - - - - -
- - -
- - - - - -外部の HTTP 認証サーバを利用した IMAP/POP3 バックエンドへのユーザリダイレクト - - - -外部の HTTP 認証サーバと内部 SMTP バックエンドへの接続リダイレクトを利用したユーザ認証 - - - -認証メソッド: - - - - -POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -SMTP: AUTH LOGIN/PLAIN/CRAM-MD5; - - - - - - -SSL サポート - - - -STARTTLS と STLS のサポート - - - - - -
- - -
- - - - - -一つのマスタープロセスと複数のワーカープロセス。ワーカーは非特権ユーザとして動く - - - -通知メソッド: kqueue (FreeBSD 4.1+)、epoll (Linux 2.6+)、rt シグナルs (Linux 2.2.19+)、/dev/poll (Solaris 7 11/99+)、イベントポート (Solaris 10)、select、poll - - - -EV_CLEAR, EV_DISABLE (イベントを一時的に無効にする)、 NOTE_LOWAT, EV_EOF、利用可能なデータの数、エラーコードを含む様々な kqueue 機能のサポート - - - -sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5)、sendfile64 (Linux 2.4.21+)、sendfilev (Solaris 8 7/01+) のサポート - - - -ファイル AIO (FreeBSD 4.3+, Linux 2.6.22+) - - - -Accept-filters (FreeBSD 4.1+) と TCP_DEFER_ACCEPT (Linux 2.4+) のサポート - - - -1 万の非アクティブな HTTP キープアライブ接続は約 2.5M のメモリーを使用 - - - -データコピーの実施は最小に保たれる - - - - - -
- - -
- - - - - -FreeBSD 3—8 / i386; FreeBSD 5—8 / amd64; - - - -Linux 2.2—2.6 / i386; Linux 2.6 / amd64; - - - -Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; - - - -MacOS X / ppc, i386; - - - -Windows XP, Windows Server 2003. - - - - - -
- - -
diff --git a/xml/menu.xml b/xml/menu.xml --- a/xml/menu.xml +++ b/xml/menu.xml @@ -7,57 +7,12 @@ - - - english - русский - - - - - 新闻 - nginx 介绍 - 下载 - 安全漏洞 - 文档 - FAQ - 书籍 - 支持 - - - trac - twitter - blog - - - unit - njs - - - - english русский - - news @@ -96,92 +51,12 @@ - - - english - русский - - - - - חדשות - אודות - הורדה - דיווחי אבטחה - תיעוד - שאלות נפוצות - תמיכה - - - trac - twitter - blog - - - unit - njs - - - - - - - english - русский - - - - - ニュース - nginx について - ダウンロード - セキュリティ情報 - ドキュメント - faq - 本 - サポート - - - trac - twitter - blog - - - unit - njs - - - - english русский - - новости об nginx скачать @@ -202,77 +77,4 @@ - - - - english - русский - - - - - haberler - hakkında - indir - - güvenlik tavsiyeleri - dökümantasyon - sss - kitaplar - destek - - - trac - twitter - blog - - - unit - njs - - - - - - - english - русский - - - - - informazioni generali - download - avvisi di sicurezza - documentazione - faq - collegamenti - libri - supporto - - - trac - twitter - blog - - - unit - njs - - - diff --git a/xml/tr/GNUmakefile b/xml/tr/GNUmakefile deleted file mode 100644 --- a/xml/tr/GNUmakefile +++ /dev/null @@ -1,11 +0,0 @@ -DOCS = \ - faq \ - windows \ - http/request_processing \ - http/server_names \ - http/configuring_https_servers \ - debugging_log \ - http/converting_rewrite_rules \ - -FAQ = \ - sys_errlist \ diff --git a/xml/tr/docs/debugging_log.xml b/xml/tr/docs/debugging_log.xml deleted file mode 100644 --- a/xml/tr/docs/debugging_log.xml +++ /dev/null @@ -1,61 +0,0 @@ - - -
- -
- - -Hata ayıklama kayıt işlemini olanaklı kılmak için, nginxi debug komutu ile yapılandırmalısınız: - - -./configure --with-debug ... - - -ve daha sonra error_log ile debug dizin yolunu belirtin: - - -error_log /path/to/log debug; - - -nginx/Windows binary versiyonu, varsayılan olarak hata ayıklama kayıt desteği ile gelir. Bu yüzden yalnızca debug dizin yolunu belirtmek yeterlidir. - - - -Not: başka düzeyde bulunan tanımlı bir kayıt (örneğin server üzerinde), diğer hata ayıklama kaydını etkisizleştirir: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log; - ... - -Ya bu sunucudaki kaydı yorum ifadesi ile kapatmalı ya da debug etiketini (flag) buraya da eklemelisiniz: - -error_log /path/to/log debug; - -http { - server { - error_log /path/to/log debug; - ... - - - - -Hata ayıklama kayıt işlemini belirli adresler için de belirleyebilirsiniz: - - -error_log /path/to/log; - -events { - debug_connection 192.168.1.1; - debug_connection 192.168.10.0/24; -} - - - -
- -
diff --git a/xml/tr/docs/faq.xml b/xml/tr/docs/faq.xml deleted file mode 100644 --- a/xml/tr/docs/faq.xml +++ /dev/null @@ -1,21 +0,0 @@ - - -
- -
- - - - - - - - - - - -
- -
diff --git a/xml/tr/docs/http/configuring_https_servers.xml b/xml/tr/docs/http/configuring_https_servers.xml deleted file mode 100644 --- a/xml/tr/docs/http/configuring_https_servers.xml +++ /dev/null @@ -1,377 +0,0 @@ - - -
- -
- - -Bir HTTPS sunucusunu yapılandırmak için, server bloğu içerisinde SSL’i etkin hale getirmeli ve sunucu sertifikası ve özel anahtar dosyaları belirtmelisiniz: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1; - ssl_ciphers HIGH:!ADH:!MD5; - ... -} - - -Sunucu sertifikası herkese açık bir birimdir. Sunucuya bağlanan her istemciye gönderilir. Özel anahtar ise gizli bir birimdir ve erişimi engellenmiş bir alanda saklanır. Ancak nginx’in ana işlemi tarafından okunabilir olmalıdır. Özel anahtar, alternatif olarak sertifika ile aynı dosya içerisinde saklanabilir: - - - ssl_certificate www.example.com.cert; - ssl_certificate_key www.example.com.cert; - - -Bu durumda dosya erişimi kısıtlanmalıdır. Aynı dosyada yer alsalar da istemciye sadece sertifika gönderilir. - - - -ssl_protocols ve ssl_ciphers yönergeleri, güçlü SSL protokol ve şifrelere (cipher) yapılan bağlantılara limit koymak için kullanılır. Versiyon 0.8.20 ile birlikte nginx, ssl_protocols SSLv3 TLSv1 ve ssl_ciphers HIGH:!ADH:!MD5 yönergelerini varsayılan olarak kullanır, bu nedenle sadece daha önceki versiyonlarda yapılandırmaya eklenmelidir. - - -
- - -
- - -SSL işlemleri ekstra işlemci (CPU) kaynakları tüketir. Çok-işlemcili sistemlerde birçok işçi işlemler yürütmelisiniz: Mevcut işlemci çekirdek sayısından az olmamalı. En yoğun işlemci-yoğun işlem SSL el sıkışmalarıdır (ÇN: SSL Handshake, kısaca sunucuda bulunan sertifikanın istemci bilgisayar tarafından onaylanması ve tekrar sunucuya bildirilmesi sürecidir). Her bir istemci için mevcut bu işlemlerin sayısını azaltmanın iki yolu vardır: İlki, keep-alive bağlantıları olanaklı kılarak bir çok talebi sadece bir bağlantı ile göndermek ve ikincisi ise SSL oturum parametrelerini tekrar kullanarak paralel ve izleyen (subsequent) bağlantılar için SSL el sıkışmalarından kaçınmaktır. - -Oturumlar, bir ssl_session_cache yönergesi tarafından yapılandırılan ve işçiler arasında paylaştırılmış bir SSL oturum önbelleğinde yer alır. Bir megabyte önbellek yaklaşık 4000 oturum içerir. Varsayılan önbellek zaman aşımı 5 dakikadır. ssl_session_timeout yönergesi ile bu süre arttırılabilir. 10M paylaşımlı oturum önbelleğine sahip bir quad core sistem için örnek yapılandırma: - - -worker_processes 4; - -http { - ssl_session_cache shared:SSL:10m; - ssl_session_timeout 10m; - - server { - listen 443; - server_name www.example.com; - keepalive_timeout 70; - - ssl on; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ssl_protocols SSLv3 TLSv1; - ssl_ciphers HIGH:!ADH:!MD5; - ... - - - -
- - -
- - -Bazı tarayıcılar popüler bir sertifika otoritesi tarafından imzalanmış sertifikaları sorunsuz kabul ederken, diğerleri sorun çıkarabilir. Bunun nedeni sertifika otoritesinin, sunucu sertifikasını, güvenilir sertifika veri tabanında yer almayan aracı bir sertifikayı kullanarak imzalamış olmasıdır. Bu durumda otorite, imzalanmış sertifikaya art arda bağlanması gereken bir dizi sertifika zinciri sunar. Bir araya geldikleri dosyada ilk önce sunucu sertifikası daha sonra zincirlenmiş sertifikalar yer almalıdır: - - -$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt - - -Oluşan dosya ssl_certificate yönergesi içinde kullanılmalıdır: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.chained.crt; - ssl_certificate_key www.example.com.key; - ... -} - - -Eğer bu art arda diziliş yanlış yapılmış olursa, nginx başlamayacak ve aşağıdakine benzer bir hata mesajını verecektir: - - -SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed - (SSL: error:0B080074:x509 certificate routines: - X509_check_private_key:key values mismatch) - - -Bu durum, nginx’in sunucu sertifikası yerine zincirlenmiş sertifikaların ilkinin özel anahtarını kullanmaya çalışması sonucu oluşur. - - - -Tarayıcılar, güvenilir otoriteler tarafından imzalanmış aracı sertifikaları genellikle depolarlar. Bu nedenle tarayıcı aracı sertifikaları daha önceden depolamış olabileceğinden zincirlenmiş sertifikalara ihtiyaç duymadan sertifika hakkında uyarı vermezler. Diğer taraftan sunucunun sertifika zincir dizisini tam olarak gönderdiğinden emin olmak için openssl komutunu kullanabilirsiniz: - - -$ 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/CN=www.GoDaddy.com - /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=ValiCert, Inc. - /OU=ValiCert Class 2 Policy Validation Authority - /CN=http://www.valicert.com//emailAddress=info@valicert.com -... - - -Bu örnekte www.GoDaddy.com sunucu sertifikasının (server certificate #0) “s” ile belirtilen konusu (subject), “i” ile gösterilen ve aynı zamanda kendisi de sonraki sertifikanın (certificate #1) konusu (subject) olan, sertifikayı veren/yayınlayan (issuer) tarafından imzalanır. Sonraki sertifika (certificate #1) ise bir sonraki sertifika (certificate #2) tarafından imzalanmıştır ve bu son sertifika ValiCert, Inc. tarafından imzalanmıştır. Bu firmanın sertifikası, tarayıcının kurulumuyla gelen sertifika veritabanında bulunur. - - - -Eğer sertifika dizisi eklemediyseniz, yalnızca bir sunucu sertifikası görürsünüz (server certificate #0). - - -
- - -
- - -En baştan HTTP ve HTTPS protokollerini ayrı yapılandırmak en iyisidir. Mevcut durumda fonksiyonellikleri aynı gözükmekle birlikte, bu gelecekte önemli bir şekilde değişebilir ve birleştirilmiş bir sunucu problemli olabilir. Ancak, eğer HTTP ve HTTPS sunucuları eşit ise ve geleceği düşünmek istemiyorsanız, ssl on yönergesini silerek ve *:443 portu için ssl parametresi ekleyerek, HTTP ve HTTPS taleplerini tutan yalnızca bir sunucu yapılandırabilirsiniz: - - -server { - listen 80; - listen 443 ssl; - server_name www.example.com; - ssl_certificate www.example.com.crt; - ssl_certificate_key www.example.com.key; - ... -} - - - -Versiyon 0.8.21 öncesi, nginx yalnızca default parametresine sahip listen soketlerinde ssl parametresinin eklenmesine izin veriyordu: - -listen 443 default ssl; - - - - -
- - -
- - -Bir IP adresini dinleyen iki veya daha fazla HTTPS sunucusunu yapılandırdığınız zaman genel bir problem ortaya çıkar: - - -server { - listen 443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - -Bu yapılandırmada, bir tarayıcı talep edilen sunucuya bakmadan, varsayılan sunucunun sertifikasını alır, örneğin: www.example.com. Bu SSL protokolüne özgü bir durumdan kaynaklanır. SSL bağlantısı, tarayıcının HTTP talebi göndermesinden önce kurulur ve nginx talep edilen sunucunun adını bilmez. Bu nedenle yalnızca varsayılan sunucunun sertifikasını önerir. - - - -Bu problemi çözmenin en eski ve sağlam methodu HTTPS sunucularının her birine ayrı IP adresleri atamaktır: - - -server { - listen 192.168.1.1:443; - server_name www.example.com; - ssl on; - ssl_certificate www.example.com.crt; - ... -} - -server { - listen 192.168.1.2:443; - server_name www.example.org; - ssl on; - ssl_certificate www.example.org.crt; - ... -} - - - -
- - -
- - -Bir tekil IP’yi birçok HTTPS sunucu arasında paylaştırmanın başka yolları da vardır, ancak bunların hepsi dezavantajlara sahiptir. Bunlardan biri, birçok ad içeren bir sertifikanın, SubjectAltName sertifika alanında kullanılmasıdır. Örneğin: www.example.com ve www.example.org. Ancak SubjectAltName alan uzunluğu sınırlandırılmıştır. - - - -Diğer bir yol ise bir sertifikayı bir wildcard adı ile birlikte kullanmaktır. Örneğin: *.example.org. Bu sertifika www.example.org ile eşleşir ancak example.org ve www.sub.example.org ile eşleşmez. Bu iki method birlikte de kullanılabilir. Bir sertifika SubjectAltName alanı içerisinde gerçek ve wildcard adlarını içerebilir. Örneğin: example.org ve *.example.org. - - - -Tüm sunuculardaki tekil hafıza kopyalarını devralması için, birçok ad içeren bir sertifika dosyası ve onun özel anahtar dosyasını, yapılandırmanın http düzeyinde bulundurmak en iyisidir: - - -ssl_certificate common.crt; -ssl_certificate_key common.key; - -server { - listen 443; - server_name www.example.com; - ssl on; - ... -} - -server { - listen 443; - server_name www.example.org; - ssl on; - ... -} - - - -
- - -
- - -Bir IP adresi üzerinde birçok HTTPS sunucusu yürütebilmenin en genel yollarından biri, bir SSL el sıkışması (handshake) sırasında, tarayıcının talep edilmiş bir sunucu adını iletmesine izin veren ve böylece sunucunun varsayılan bağlantı için hangi sertifikayı kullanacağını bilmesini sağlayan TLSv1.1 Server Name Indication eklentisidir (SNI, RFC3546). Ancak SNI, kısıtlı bir tarayıcı desteğine sahiptir. Mevcut destekleyen tarayıcılar ve versiyonları: - - - - - -Opera 8.0; - - - -MSIE 7.0 (sadece Windows Vista ve üstü); - - - -Firefox 2.0 ve Mozilla Platform rv:1.8.1 platformunu kullanan diğer tarayıcılar; - - - -Safari 3.2.1 (Windows Vista ve üstü); - - - -Chrome (Windows Vista ve üstü). - - - - - -nginx içerisinde SNI kullanabilmek için, hem nginx ile birlikte yüklenen OpenSSL kütüphanesi hem de yürütüm süresi (run time) üzerinde dinamik olarak bağlatılanmış diğer kütüphaneler tarafından desteklenmiş olmalıdır. Versiyon 0.9.8f itibari ile “--enable-tlsext” yapılandırma opsiyonu ile birlikte OpenSSL, SNI desteği sunmaktadır. OpenSSL 0.9.8j itibari ile varsayılan olarak etkindir. Eğer nginx, SNI desteği ile yüklenirse “-V” anahtarını girdiğinizde aşağıdaki çıktı ile karşılaşırsınız: - - -$ nginx -V -... -TLS SNI support enabled -... - - -Ama eğer SNI-etkin nginx, SNI desteği olmadan dinamik olarak OpenSSL’e bağlantılanırsa, aşağıdaki hata ile karşılaşırsınız: - - -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 - - - -
- - -
- - - - - -Versiyon 0.8.21 ve 0.7.62 ile birlikte SNI destek statüsü “-V” anahtarı ile birlikte görüntülenmeye başlandı. - - - -Versiyon 0.7.14 ile birlikte listen yönergesinin ssl parametresi desteklenmeye başlandı. - - - -Versiyon 0.5.32 ile birlikte SNI desteği gelmiştir. - - - -Versiyon 0.5.6 ile birlikte paylaşımlı SSL otorum önbelleği desteği gelmiştir. - - - - - - - - - -Versiyon 0.7.65, 0.8.19 ve sonrası varsayılan SSL protokolleri: SSLv3 ve TLSv1. - - - -Versiyon 0.7.64, 0.8.18 ve öncesi varsayılan SSL protokolleri: SSLv2, SSLv3 ve TLSv1. - - - - - - - - - -Versiyon 0.7.65, 0.8.20 ve sonrası varsayılan SSL şifreleri (cipher): -HIGH:!ADH:!MD5. - - - -Versiyon 0.8.19: varsayılan SSL şifreleri: -ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM. - - - -Versiyon 0.7.64, 0.8.18 ve öncesi varsayılan SSL şifreleri:
-ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. - - - - - - -
- - -
diff --git a/xml/tr/docs/http/converting_rewrite_rules.xml b/xml/tr/docs/http/converting_rewrite_rules.xml deleted file mode 100644 --- a/xml/tr/docs/http/converting_rewrite_rules.xml +++ /dev/null @@ -1,127 +0,0 @@ - - -
- -
- - -Paylaşımlı hosting kullananlar genelde her şeyi, sadece Apache’nin .htaccess dosyalarını yapılandırarak kullanırlar. Bu dosyada bulunan kuralların çevirisine örnek olarak: - - -RewriteCond %{HTTP_HOST} example.org -RewriteRule (.*) http://www.example.org$1 - - -kuralı, nginx içerisinde şu şekilde yapılıyor: - - -server { - listen 80; - server_name www.example.org example.org; - if ($http_host = example.org) { - rewrite (.*) http://www.example.org$1; - } - ... -} - - - - -Bu yanlış, kullanışsız ve etkisiz bir yoldur. Doğru olan ayrı bir sunucu tanımlaması yapmaktır: - - -server { - listen 80; - server_name example.org; - rewrite ^ http://www.example.org$request_uri?; -} - -server { - listen 80; - server_name www.example.org; - ... -} - - - -
- - -
- - -Diğer bir örnek ile aşağıdaki geri kalmış mantık yerine (example.com olmayan her şey ve www.example.com olmayan her şey): - - -RewriteCond %{HTTP_HOST} !example.com -RewriteCond %{HTTP_HOST} !www.example.com -RewriteRule (.*) http://www.example.com$1 - - -sadece example.com, www.example.com ve diğer her şeyi ayrı ayrı tanımlamalısınız: - - -server { - listen 80; - server_name example.com www.example.com; - ... -} - -server { - listen 80 default_server; - server_name _; - rewrite ^ http://example.com$request_uri?; -} - - - -
- - -
- - -Tipik Mongrel kuralları: - - -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] - - -şu şekilde dönüştürülmelidir: - - -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; -} - - - -
- -
diff --git a/xml/tr/docs/http/request_processing.xml b/xml/tr/docs/http/request_processing.xml deleted file mode 100644 --- a/xml/tr/docs/http/request_processing.xml +++ /dev/null @@ -1,222 +0,0 @@ - - -
- -
- - -nginx, ilk olarak hangi sunucunun talebi işleyeceğine karar verir. -80 portunu dinleyen 3 sunucunun olduğu bir yapılandırma ile örnek verelim: - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name example.net www.example.net; - ... -} - -server { - listen 80; - server_name example.com www.example.com; - ... -} - - - - -Bu yapılandırmada, nginx yalnızca talebin header bilgisinde bulunan “Host” datasını kullanarak hangi sunucunun cevap vereceğini belirliyor. -Eğer “Host” datası boş ise veya herhangi bir sunucu adı ile eşleşmez ise nginx talebi varsayılan sunucuya yönlendirir. -Yukarıdaki örnekte varsayılan sunucu ilk server ifadesi kabul edilir. -Eğer ilk server ifadesinin varsayılan olmasını istemiyorsanız, listen yönergesinde default_server parametresini kullanabilirsiniz: - - -server { - listen 80 default_server; - server_name example.net www.example.net; - ... -} - - - -default_server parametresi, versiyon 0.8.21 ile birlikte kullanılmaya başlanmıştır. -Önceki versiyonlarda default parametresi kullanılmalıdır. - - -Not: Varsayılan sunucu, sunucu adının değil listen portunun bir özelliğidir. Daha sonra bu konuya değinilecek. - - -
- - -
- - -Eğer tanımlanmamış “Host” bilgisine sahip talepleri işlemek istemiyorsanız, bu talepleri düşüren bir varsayılan sunucu tanımlayabilirsiniz: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -Böylece var olmayan alan adı için “_” ifadesini kullanarak nginx’in standart olmayan 444 koduna yönlendirerek bağlantıyı kapatıyoruz. -Not: Bu sunucu için bir ad belirlemelisiniz. Aksi takdirde nginx hostname ifadesini kullanacaktır. - - -
- - -
- - -Farklı adreslerde bulunan sanal sunucuların yer aldığı biraz daha karışık bir yapılandırmayı inceleyelim: - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80; - server_name example.com www.example.com; - ... -} - - -Bu yapılandırmada, nginx server bloklarında yer alan listen yönergelerini ilk olarak IP adresi ve port üzerinde test eder. Daha sonra, gelen taleplerin header bilgisinde yer alan “Host” datasını, IP ve port ile eşleşen server bloklarında yer alan server_name girdileri ile kontrol eder. - -Eğer sunucu bulunamazsa varsayılan sunucu tarafından işlenir. Örneğin, www.example.com için 192.168.1.1:80 adres ve portuna gelen bir talep, eğer bu adres ve port için www.example.com tanımlanmamışsa, 192.168.1.1:80’e ait varsayılan sunucu tarafından işlenir. - - - -Daha önce belirtildiği gibi, varsayılan bir sunucu, bir listen portunun ve değişik listen portları için tanımlanan çeşitli varsayılan sunucuların özelliğidir: - - -server { - listen 192.168.1.1:80; - server_name example.org www.example.org; - ... -} - -server { - listen 192.168.1.1:80 default_server; - server_name example.net www.example.net; - ... -} - -server { - listen 192.168.1.2:80 default_server; - server_name example.com www.example.com; - ... -} - - - -
- - -
- - -nginx’in basit bir PHP sitesi için gelen talebi işlemek için nasıl bir lokasyon seçtiğini inceleyelim: - - -server { - listen 80; - server_name example.org www.example.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; - } -} - - - - -nginx ilk olarak literal dizgiler (string) tarafından verilmiş en spesifik lokasyonları arar. Yukarıdaki yapılandırmada tek literal lokasyon / ifadesidir ve herhangi bir talep ile eşleştiğinde kullanılacak son uğraktır (resort). nginx, daha sonra yapılandırma dosyasında bulunan listelenmiş sıralardaki düzenli ifadeler tarafından verilmiş lokasyonları arar. İlk düzenli ifade eşleşmesi aramayı durdurur ve nginx bu lokasyonu kullanır. Eğer talep ile eşleşen bir düzenli ifade bulunamaz ise nginx daha önce bulduğu en spesifik lokasyonu kullanır. - - - -Not: Tüm tiplerde bulunan bu lokasyonlar sadece bir talebin, sorgu dizgisi olmayan URI datasını test eder. Bunun yapılmasının nedeni sorgu dizgisinde bulunan argümanların çeşitli yollarla verilebilmesidir, örneğin: - - -/index.php?user=john&page=1 -/index.php?page=1&user=john - - -Ayrıca herhangi biri, herhangi bir şeyi sorgu dizgileri ile talep edebilir: - - -/index.php?page=1&baska+bir+sey&user=john - - - - -Yukarıdaki yapılandırmada taleplerin nasıl işlendiğini inceleyelim: - - - - - -Bir /logo.gif talebi, ilk olarak / literal lokasyonu, daha sonra, \.(gif|jpg|png)$ düzenli ifadesi tarafından eşleştirilir. Bu sonraki (latter) lokasyon tarafından tutulur. root /data/www yönergesi kullanılarak, talep /data/www/logo.gif dosyasına eşlemlenir (mapped to) ve dosya istemciye gönderilir. - - - - - -Bir /index.php talebi de ilk olarak / literal lokasyonu, sonra, \.(php)$ düzenli ifadesi tarafından eşleştirilir. Bu nedenle sonraki lokasyon tarafından tutulur ve localhost:9000’in dinlendiği bir FastCGI sunucusuna iletilir. fastcgi_param yönergesi, SCRIPT_FILENAME FastCGI parametresini /data/www/index.php adresine yerleştirir ve FastCGI sunucusu dosyayı yürütür. $document_root değişkeni root yönergesinin değerine, $fastcgi_script_name değişkeni ise talebin URI değerine eşittir. Örneğin /index.php. - - - - - -Bir /about.html talebi yalnızca / literal lokasyonu tarafından eşleştirilir ve bu yüzden, bu lokasyon tarafından tutulur. root /data/www yönergesi kullanılarak talep, /data/www/about.html dosyasına eşlemlenir ve istemciye gönderilir. - - - - - -Bir / talebini tutmak daha karmaşıktır. Sadece / literal lokasyonu tarafından eşleştirilir ve bu yüzden bu lokasyon tarafından tutulur. Sonra index yönergesi parametrelerine ve root /data/www yönergesine göre bir index dosyası olup olmadığını kontrol eder. Eğer bir /data/www/index.php dosyası mevcut ise yönerge, /index.php adresine dahili bir yönlendirme yapar ve eğer talep bir istemci tarafından gönderilmiş ise nginx, lokasyonları tekrar arar. Daha önce gördüğümüz gibi, yönlendirilmiş talep en son olarak FastCGI sunucusu tarafından tutulur. - - - - - - -
- -
diff --git a/xml/tr/docs/http/server_names.xml b/xml/tr/docs/http/server_names.xml deleted file mode 100644 --- a/xml/tr/docs/http/server_names.xml +++ /dev/null @@ -1,354 +0,0 @@ - - -
- -
- - -Sunucu adları server_name yönergesi kullanılarak tanımlanırlar ve gelen bir talep için hangi server bloğunun kullanılacağını belirlerler. Ayrıca bakınız “”. Gerçek, wildcard veya düzenli ifadeler şeklinde tanımlanabilirler. - - -server { - listen 80; - server_name example.org www.example.org; - ... -} - -server { - listen 80; - server_name *.example.org; - ... -} - -server { - listen 80; - server_name mail.*; - ... -} - -server { - listen 80; - server_name ~^(?<user>.+)\.example\.net$; - ... -} - - -Bu adlar şu sıra ile test edilirler: - - - - -gerçek adlar; - - - -* ile başlayan wildcard adlar: *.example.org; - - - -* ile biten wildcard adlar: mail.*; - - - -ve düzenli ifadeler (regular expressions). - - - -İlk eşleşme arama işlemini bitirir. - - -
- - -
- - -Bir wildcard ad ancak başlangıçta veya bitişte * ifadesini içerir ve nokta ile sınırlandırılır. www.*.example.org ve w*.example.org adları geçersizdir. Ancak bu adlar düzenli ifadeler ile geçerli hale getirilebilir, örneğin, ~^www\..+\.example\.org$ ve ~^w.*\.example\.org$. Buradaki * bir çok eşleşmeyi tanımlayabilir. *.example.org ifadesi www.example.org ve www.sub.example.org adlarına karşılık gelebilir. - - - -.example.org şeklindeki bir wildcard example.org gerçek adı ile *.example.org wildcard adına karşılık gelir. - - -
- - -
- - -nginx tarafından kullanılan düzenli ifadeler, Perl programlama dili (PCRE) tarafından kullanılanlar ile tam uyumludur. -Bir düzenli ifade kullanmak için sunucu adı tilda (~) ile başlamalıdır: - - -server_name ~^www\d+\.example\.net$; - - -diğer türlü ifade gerçek ad veya düzenli ifade * içeriyorsa wildcard ad gibi algılanacaktır (ve yüksek ihtimal geçersiz bir ad olarak). -“^” ve “$” çapalarını kullanmayı unutmayın. -Sentaks açısından gerekli olmasalar da mantık açısından gereklidir. -Ayrıca alan adında bulunan noktalarda da \ önceli ile kullanılmalıdır. -“{” ve “}” kullanan bir düzenli ifade tırnak arasına alınmalıdır: - - -server_name "~^(?<name>\w\d{1,3}+)\.example\.net$"; - - -diğer türlü, nginx şu şekilde bir hata verecektir: - - -directive "server_name" is not terminated by ";" in ... - - -Bir düzenli ifade adı değişken olarak sonraki aşamalarda kullanılabilir: - - -server { - server_name ~^(www\.)?(?<domain>.+)$; - - location / { - root /sites/$domain; - } -} - - -PCRE kütüphanesi ile ad yakalama işlemi de şu şekildedir: - - - - - - - - - - - - - - - - - - -
?<name>Perl 5.10 uyumlu sentaks, PCRE-7.0 ile gelmiştir.
?'name'Perl 5.10 uyumlu sentaks, PCRE-7.0 ile gelmiştir.
?P<name>Python uyumlu sentaks, PCRE-4.0 ile gelmiştir.
- -Eğer nginx aşağıdaki hatayı verirse: - - -pcre_compile() failed: unrecognized character after (?< in ... - - -bu PCRE kütüphanesini eski olduğu ve ?P<name> şeklinde kullanmanız gerektiği anlamına gelir. -Yakalama ayrıca dijital formda da olabilir: - - -server { - server_name ~^(www\.)?(.+)$; - - location / { - root /sites/$2; - } -} - - -Ancak, dijital referanslar kolaylıkla üstüne yazılabilir olduğundan, bu şekilde kullanım basit durumlar için sınırlandırılmalıdır (yukarıdaki gibi). - - - -
- - -
- - -Eğer server bloğu içerisinde bir server_name tanımlanmamışsa nginx, sunucu adı olarak hostname ifadesini kullanır. - - - -Eğer varsayılan dışındaki bir server bloğuna gelen ve header bilgisinde “Host” datası yer almayan bir talebi işlemek isterseniz boş bir ad kullanmak zorundasınız: - - -server { - listen 80; - server_name example.org www.example.org ""; - ... -} - - - - -Eğer bir istemci ad yerine IP adresini kullanarak bir talepte bulunursa, header içerisinde bulunan “Host” datası IP bilgisini içerecektir ve bu IP adresini, sunucu adı olarak kullanarak talebi işleyebilirsiniz: - - -server { - listen 80; - server_name example.org - www.example.org - "" - 192.168.1.1 - ; - ... -} - - - - -Bir catch-all (tümünü-yakala) sunucuda “_” şeklinde garip bir ifade ile karşılaşabilirsiniz: - - -server { - listen 80 default_server; - server_name _; - return 444; -} - - -Bu ad ile ilgili özel bir durum söz konusu değil, sadece gerçek bir ad ile kesişmeyen sayısız geçersiz alan adlarından biridir. -Ayrıca “--”, “!@#” ve benzeri ifadeler de kullanabilirsiniz. - - - -nginx, 0.6.25 versiyonuna kadar, bir catch-all adı olmak için hatalı bir şekilde yorumlanan “*” özel adını destekliyordu. -Fakat bu bir catch-all veya wildcard sunucu adı olarak fonksiyonel değil. Bunun yerine, server_name_in_redirect yönergesini kullanarak fonksiyonelliği sağlamaya başladık. -“*” özel karakteri artık desteklenmiyor, bu yüzden server_name_in_redirect yönergesi kullanılmalıdır. -Not: server_name yönergesini kullanan varsayılan sunucuyu veya catch-all adını belirtmenin bir yolu bulunmuyor. -Bu, server_name yönergesinin değil, listen yönergesinin bir özelliğidir. -Ayrıca bakınız “”. -*:80 ve *:8080 portlarını dinleyen sunucular tanımlayabilir ve birini *:8080 portu için varsayılan olarak belirlerken, diğerini de *:80 için varsayılan olarak belirleyebilirsiniz: - - -server { - listen 80; - listen 8080 default_server; - server_name example.net; - ... -} - -server { - listen 80 default_server; - listen 8080; - server_name example.org; - ... -} - - - - -
- - -
- - -Gerçek ve wildcard adlar çırpılarda (hash) depolanır. Çırpılar listen portlarına bağlıdırlar ve her bir listen port 3 farklı çırpıya sahip olabilir: gerçek ad çırpısı, * ile başlayan bir wildcard adı çırpısı ve * ile biten bir wildcard adı çırpısı. Çırpıların boyutu yapılandırma aşamasında optimize edilir ve böylece bir ad en az önbellek kayıpları ile bulundurulur. İlk olarak gerçek ad çırpısı aranır. Gerçek ad çırpısı kullanan bir ad bulunmaz ise, * ile başlayan wildcard ad çırpısı aranır. Bu da bulunmaz ise, * ile biten wildcard ad çırpısı aranır. Adların alanadı parçaları ile aranması nedeniyle wildcard ad çırpıları araması, gerçek ad çırpı aramasına oranla daha yavaştır. Not: Özel .example.org wildcard formu, gerçek ad çırpısında değil, wildcard ad çırpısında saklanır. Düzenli İfadeler sırayla test edildiğinden bu en yavaş ve ölçeklenebilir olmayan yöntemdir. - - - -Bu nedenlerden dolayı, imkanlar el veriyorsa gerçek adları kullanmak en iyisidir. Örneğin, bir sunucunun en sık talep edilen adları example.org ve www.example.org ise bunları açıkca belirtmek daha etkili olacaktır: - - -server { - listen 80; - server_name example.org www.example.org *.example.org; - ... -} - - -bu kullanım aşağıdaki basit kullanımdan daha etkili olacaktır: - - -server { - listen 80; - server_name .example.org; - ... -} - - - - -Eğer çok miktarda veya olağandışı şekilde uzun sunucu adları tanımladıysanız, http düzeyinde server_names_hash_max_size -ve server_names_hash_bucket_size yönergelerini tekrar ayarlamalısınız. server_names_hash_bucket_size yönergesinin varsayılan değeri CPU önbellek satır boyutuna göre 32, 64 veya başka bir rakam olabilir. Eğer bu değer 32 ise ve “cok.uzun.sunucu.adi.example.org” ifadesini sunucu adı olarak belirlerseniz nginx, başlamayacak ve aşağıdaki hatayı verecektir: - - -could not build the server_names_hash, -you should increase server_names_hash_bucket_size: 32 - - -Bu durumda yönerge değerini aşağıdaki gibi belirlemelisiniz: - - -http { - server_names_hash_bucket_size 64; - ... - - -Eğer çok fazla sunu adı belirlemiş iseniz şu şekilde bir hata alacaksınız: - - -could not build the server_names_hash, -you should increase either server_names_hash_max_size: 512 -or server_names_hash_bucket_size: 32 - - -Bu durumda ilk olarak server_names_hash_max_size değerini sunucu ad sayısına yakın bir değeri yükseltin. Eğer bu da yardımcı sorunu çözmez ise veya nginx başlama süresi çok uzar ise server_names_hash_bucket_size değerini arttırın. - - - -Eğer bir sunucu sadece bir listen port için ise, nginx sunucu adlarını test etmeyecek ve listen port için çırpılar yaratmayacaktır. Fakat bu durumun bir istisnası var; eğer server_name tutuklar (capture) içeren bir düzenli ifade ise nginx, bu tutukları almak için ifadeyi yürütmek zorundadır. - - -
- - -
- - - - - -Named düzenli ifade sunucu adı tutukları, 0.8.25 versiyonundan beri destekleniyor. - - - -Düzenli ifade sunucu adı tutukları, 0.7.40 versiyonundan beri destekleniyor. - - - -“” boş sunucu adı 0.7.12 versiyonundan beri destekleniyor. - - - -Bir wildcard sunucu adının veya düzenli ifadenin ilk sunucu adı olarak kullanılması 0.6.25 versiyonundan beri destekleniyor. - - - -Düzenli ifade sunucu adları 0.6.7 versiyonundan beri destekleniyor. - - - -example.* wildcard formu 0.6.0 versiyonundan beri destekleniyor. - - - -.example.org özel formu 0.3.18 versiyonundan beri destekleniyor. - - - -*.example.org wildcard formu 0.1.13 versiyonundan beri destekleniyor. - - - - - -
- -
diff --git a/xml/tr/docs/index.xml b/xml/tr/docs/index.xml deleted file mode 100644 --- a/xml/tr/docs/index.xml +++ /dev/null @@ -1,54 +0,0 @@ - - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
- - - - - - - - - - - -
- -
diff --git a/xml/tr/docs/sys_errlist.xml b/xml/tr/docs/sys_errlist.xml deleted file mode 100644 --- a/xml/tr/docs/sys_errlist.xml +++ /dev/null @@ -1,27 +0,0 @@ - - -
- -
- - -nginx versiyon 0.7.66, 0.8.35 ve üstü için Linux kurulumu yaparken, şu uyarıları alabilirsiniz: - - -warning: `sys_errlist' is deprecated; - use `strerror' or `strerror_r' instead -warning: `sys_nerr' is deprecated; - use `strerror' or `strerror_r' instead - - -Bu normal bir durum: strerror() ve strerror_r() fonksiyonları "Async-Signal-Safe" olmadığından, nginx sinyal işleyici olarak onaylı olmayan sys_errlist[] ve sys_nerr kullanmak zorundadır. - - -
- -
diff --git a/xml/tr/docs/windows.xml b/xml/tr/docs/windows.xml deleted file mode 100644 --- a/xml/tr/docs/windows.xml +++ /dev/null @@ -1,134 +0,0 @@ - - -
- -
- - -nginx/Windows doğrudan Win32 API’yi kullanır (Cygwin emülasyon tabakasını değil). -Şu an için sadece select methodunu kullandığından yüksek performans ve ölçeklenebilirlik beklememelisiniz. -Bu ve bilinen diğer nedenlerle nginx/Windows’u beta versiyon olarak kabul etmek gerekir. -Unix versiyonu ile karşılaştırıldığında, XSLT filtresi, imaj filtresi, GeoIP modülü ve gömülü Perl dili hariç tam fonklsiyoneldir. - - - -nginx/Windows versiyonunu yüklemek için indir bağlantısından zip formatındaki geliştirme versiyonunu indirebilirsiniz. Geliştirme versiyonu, özellikle Windows ile ilgili en son yamaları içerir. Dosyayı indirdikten sonra açarak, nginx- klasörü içerisinden nginx’i çalıştırabilirsiniz. -C sürücüsü için örnek. root dizini: - - -cd c:\ -unzip nginx-.zip -cd nginx- -start nginx - - -Ayrıca tasklist komutu ile nginx işlemlerini takip edebilirsiniz: - - -C:\nginx->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 - - -Bu işlemlerden biri ana, diğerleri işçi işlemleridir. -Eğer nginx başlamazsa logs\error.log dosyasından nedenini öğrenebilirsiniz. -Eğer kayıt (log) dosyası yaratılmamış ise bunun nedeni de Windows Event Log içerisinde belirtilmiştir. -Eğer beklenen sayfa yerine hata sayfası ile karşılaşırsanız, yine logs\error.log dosyasını kontrol etmelisiniz. - - - -nginx/Windows, yapılandırmada yer alan nisbi dizin yolları için yürütüldüğü klasörü, önek klasör olarak kullanır. -Buna örnek olarak, önek klasör şu şekildedir: -C:\nginx-\. -Ayarlarda yer alan dizin yolları Unix-stili kesme işaretleri ile belirtilir: - - -access_log logs/site.log; -root C:/web/html; - - - - -nginx/Windows bir servis olarak değil, standart konsol uygulaması olarak yürütülür ve aşağıdaki komutlar ile yönetilir: - - - - - - - - - - - - - - - - - - - - - - - -
nginx -s stophızlı çıkış
nginx -s quityavaş çıkış
nginx -s reload -ayarları değiştirmek, -yeni işçi çalıştırmak, -eski işçi işlemden yavaşça çıkmak -
nginx -s reopenKayıt dosyalarını tekrar açmak
- - -
- -
- - - - -Bir çok işçi yürütülebildiği halde sadece biri iş yapabilmektedir. - - - -Bir işçi, 1024 eşzamanlı bağlantıdan fazlasını karşılayamamaktadır. - - - -Paylaşımlı hafıza desteğine ihtiyaç duyan önbellek ve diğer modüller, -“address space layout randomization” etkin olduğundan, -Windows Vista ve sonraki versiyonlarda çalışmamaktadır. - - - - -
- -
- - - - -Servis olarak yürütme. - - - -I/O completion portlarını, uyarı methodu olarak kulanmak. - - - -Bir işçi işleminde (worker process) çoklu thread (yürütme birimi) kullanmak. - - - - -
- -
diff --git a/xml/tr/index.xml b/xml/tr/index.xml deleted file mode 100644 --- a/xml/tr/index.xml +++ /dev/null @@ -1,259 +0,0 @@ - - -
- - -
- - -nginx [engine x], Igor Sysoev tarafından yazılan bir HTTP, reverse proxy ve mail proxy sunucusudur. 5 yıldır, özellikle Rus sitelerinde yoğun bir şekilde kullanılmaktadır. Örneğin; -Rambler -(RamblerMedia.com). -Netcraft'a göre, nginx, Nisan 2010 itibari ile %4.70 oranında kullanılmaktadır. -Bazı başarı hikayeleri (İngilizce): -FastMail.FM, -Wordpress.com. - - - -Kaynak kodu, 2-clause BSD-like license lisansı altındadır. - - -
- - -
- - - - - -Statik ve index dosyalarının sunumu, otomatik indeksleme; -açık dosya açıklayıcı önbellek; - - - -Önbellek ile hızlandırılmış reverse proxying; -basit yük dengeleme ve hata toleransı; - - - -Uzak FastCgi sunucularının önbelleklenmesi ile hızlandırılmış destek; -basit yük dengeleme ve hata toleransı; - - - -Modüler yapı. -Gzip, byte aralıkları, yığın cevaplar (chunked responses), XSLT, SSI, imaj boyutlandırma gibi filtreler. -FastCGI veya proksilenmiş sunucular ile tek bir sayfada çoklu SSI içermelerinin paralel işlenmesi. - - - -SSL ve TLS SNI desteği. - - - - - -
- - -
- - - - - -Ad ve IP tabanlı sanal sunucular; - - - -Keep-alive ve pipelined bağlantı desteği; - - - -Esnek yapılandırma; - - - -İstemci işlemlerinde kopma olmadan yeniden yapılandırma ve online güncelleme; - - - -Erişim kayıt (log) formatları, tamponlanmış kayıt yazımı ve hızlı kayıt devri; - - - -3xx-5xx hata kod yönlendirmeleri; - - - -rewrite modülü; - - - -İstemcinin IP adresine dayalı erişim kontrolü ve HTTP temel kimlik denetleme; - - - -PUT, DELETE, MKCOL, COPY ve MOVE methodları; - - - -FLV streaming; - - - -Hız sınırlandırma; - - - -Bir adresten gelen eşzamanlı bağlantı ve talepleri sınırlandırma. - - - -Gömülü perl. - - - - - -
- - -
- - - - - -Harici bir HTTP kimlik denetleme sunucusunu kullanarak, kullanıcıyı IMAP/POP3 backend'ine yönlendirme; - - - -Harici bir HTTP kimlik denetleme sunucusunu kullanarak, kullanıcıyı SMTP backend'ine yönlendirme ve kullanıcı kimlik denetlemesi; - - - -Kimlik denetleme methodları: - - - - -POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5; - - - -SMTP: AUTH LOGIN/PLAIN/CRAM-MD5; - - - - - - -SSL desteği; - - - -STARTTLS ve STLS desteği. - - - - - -
- - -
- - - - - -Bir ana işlem (main process) ve çok sayıda işçi işlemleri (workers). -İşçiler, imtiyazsız kullanıcı olarak yürütülürler; - - - -Uyarı methodları: 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 ve poll; - - - -Çeşitli kqueue özellikleri desteği: EV_CLEAR, EV_DISABLE -(event'i geçici olarak etkisizleştirir), NOTE_LOWAT, EV_EOF, olanaklı data sayısı, -hata kodları; - - - -sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5), sendfile64 (Linux 2.4.21+), -ve sendfilev (Solaris 8 7/01+) desteği; - - - -File AIO (FreeBSD 4.3+, Linux 2.6.22+); - - - -Accept-filters (FreeBSD 4.1+) ve TCP_DEFER_ACCEPT (Linux 2.4+) desteği; - - - -10,000 inaktif HTTP keep-alive bağlantısı yaklaşık 2.5M hafıza kullanır; - - - -Data kopyalama operasyonları minimum düzeydedir. - - - - - -
- - -
- - - - - -FreeBSD 3—8 / i386; FreeBSD 5—8 / amd64; - - - -Linux 2.2—2.6 / i386; Linux 2.6 / amd64; - - - -Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v; - - - -MacOS X / ppc, i386; - - - -Windows XP, Windows Server 2003. - - - - - -
- - -
diff --git a/xsls/article.xsls b/xsls/article.xsls --- a/xsls/article.xsls +++ b/xsls/article.xsls @@ -38,10 +38,6 @@ X:include href = "versions.xslt"; X:template = "/article | /module" { - X:if "@lang = 'he'" { X:attribute "dir" { X:text{rtl} } } - - X:if "@lang = 'cn'" { X:attribute "lang" { X:text{zh-CN} } } - !{@name} diff --git a/xsls/body.xsls b/xsls/body.xsls --- a/xsls/body.xsls +++ b/xsls/body.xsls @@ -7,20 +7,11 @@ X:stylesheet { X:template body (lang) { - X:variable MENU_ALIGN = { - X:if "$lang = 'he'" { X:text {left} } else { X:text {right} } - } - - X:variable INDEX_ALIGN = { - X:if "$lang = 'he'" { X:text {right} } else { X:text {left} } - } -