# HG changeset patch # User Ruslan Ermilov # Date 1342675065 0 # Node ID 130fad6dc1b426e9738c6d8de5e0b4cc47afc4b2 # Parent d40371689c1cdaba21f2137a05c3df2e3974381f Replaced the uses of "url" element with "literal". diff -r d40371689c1c -r 130fad6dc1b4 xml/cn/docs/http/configuring_https_servers.xml --- a/xml/cn/docs/http/configuring_https_servers.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/cn/docs/http/configuring_https_servers.xml Thu Jul 19 05:17:45 2012 +0000 @@ -202,7 +202,7 @@ } -使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机的证书,比方说就是www.nginx.com。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后,才能发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 +使用上面的配置,不论浏览器请求哪个主机,都只会收到默认主机的证书,比方说就是www.nginx.com。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后,才能发送HTTP请求,所以nginx建立SSL连接时不知道所请求主机的名字,因此,它只会返回默认主机的证书。 @@ -234,11 +234,11 @@ name="带有多个主机名的SSL证书"> -也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如www.nginx.comwww.nginx.org。这种方法的限制是“SubjectAltName”字段的长度。 +也有其他一些方法可以实现多个HTTPS主机共享一个IP地址,但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书,比如www.nginx.comwww.nginx.org。这种方法的限制是“SubjectAltName”字段的长度。 -另一种方式是使用主机名中含有通配符的证书,比如*.nginx.org。这个证书匹配www.nginx.org,但是不匹配nginx.orgwww.sub.nginx.org。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书,这些名字既可以是确切的名字,也可以是通配符,比如nginx.org*.nginx.org。 +另一种方式是使用主机名中含有通配符的证书,比如*.nginx.org。这个证书匹配www.nginx.org,但是不匹配nginx.orgwww.sub.nginx.org。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书,这些名字既可以是确切的名字,也可以是通配符,比如nginx.org*.nginx.org diff -r d40371689c1c -r 130fad6dc1b4 xml/cn/docs/http/converting_rewrite_rules.xml --- a/xml/cn/docs/http/converting_rewrite_rules.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/cn/docs/http/converting_rewrite_rules.xml Thu Jul 19 05:17:45 2012 +0000 @@ -30,7 +30,7 @@ -这种做法是错的,复杂而且低效。正确的方式是为nginx.org定义一个单独的服务器: +这种做法是错的,复杂而且低效。正确的方式是为nginx.org定义一个单独的服务器: server { @@ -61,7 +61,7 @@
-再举一个例子,处理一个和刚才相反的逻辑:既不是来自nginx.com,又不是来自www.nginx.com: +再举一个例子,处理一个和刚才相反的逻辑:既不是来自nginx.com,又不是来自www.nginx.com RewriteCond %{HTTP_HOST} !nginx.com @@ -69,7 +69,7 @@ RewriteRule (.*) http://www.nginx.com$1 -应该按下面这样分开定义nginx.comwww.nginx.com和其他站点: +应该按下面这样分开定义nginx.comwww.nginx.com和其他站点: server { diff -r d40371689c1c -r 130fad6dc1b4 xml/cn/docs/http/request_processing.xml --- a/xml/cn/docs/http/request_processing.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/cn/docs/http/request_processing.xml Thu Jul 19 05:17:45 2012 +0000 @@ -100,7 +100,7 @@ } -这个配置中,nginx根据"server"配置块中的"listen"指令首先测试请求的IP地址和端口是否匹配某个定义的值。如果匹配成功,则继续测试请求的Host头是否匹配这个块中的"server_name"的值。如果主机名匹配失败,这个请求将被交给默认的虚拟主机处理。例如,一个从192.168.1.1:80端口收到的访问www.nginx.com的请求将被监听192.168.1.1:80端口的默认服务器处理,本例中就是第一个服务器,因为这个端口上没有定义域名为www.nginx.com的服务器。 +这个配置中,nginx根据"server"配置块中的"listen"指令首先测试请求的IP地址和端口是否匹配某个定义的值。如果匹配成功,则继续测试请求的Host头是否匹配这个块中的"server_name"的值。如果主机名匹配失败,这个请求将被交给默认的虚拟主机处理。例如,一个从192.168.1.1:80端口收到的访问www.nginx.com的请求将被监听192.168.1.1:80端口的默认服务器处理,本例中就是第一个服务器,因为这个端口上没有定义域名为www.nginx.com的服务器。 diff -r d40371689c1c -r 130fad6dc1b4 xml/cn/docs/http/server_names.xml --- a/xml/cn/docs/http/server_names.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/cn/docs/http/server_names.xml Thu Jul 19 05:17:45 2012 +0000 @@ -48,11 +48,11 @@ -以星号起始的通配符名字:*.nginx.org; +以星号起始的通配符名字:*.nginx.org -以星号结束的通配符名字:mail.*; +以星号结束的通配符名字:mail.* @@ -70,7 +70,7 @@ name="通配符名字"> -通配符名字只可以在名字的起始处或结尾处包含一个星号,并且星号与其他字符之间用点分隔。所以,www.*.nginx.orgw*.nginx.org都是非法的。不过,上面的两个名字可以使用正则表达式描述:~^www\..+\.nginx\.org$~^w.*\.nginx\.org$。星号可以匹配名字的多个节(各节都是以点号分隔的),比如*.nginx.org不仅匹配www.nginx.org,也匹配www.sub.nginx.org。 +通配符名字只可以在名字的起始处或结尾处包含一个星号,并且星号与其他字符之间用点分隔。所以,www.*.nginx.orgw*.nginx.org都是非法的。不过,上面的两个名字可以使用正则表达式描述:~^www\..+\.nginx\.org$~^w.*\.nginx\.org$。星号可以匹配名字的多个节(各节都是以点号分隔的),比如*.nginx.org不仅匹配www.nginx.org,也匹配www.sub.nginx.org @@ -244,7 +244,7 @@ -鉴于以上原因,请尽可能使用确切的名字。举个例子,如果使用nginx.orgwww.nginx.org来访问服务器是最频繁的,那么将它们明确的定义出来就更为有效: +鉴于以上原因,请尽可能使用确切的名字。举个例子,如果使用nginx.orgwww.nginx.org来访问服务器是最频繁的,那么将它们明确的定义出来就更为有效: server { @@ -329,15 +329,15 @@ -从0.6.0版本开始,支持形如nginx.*的通配符名字。 +从0.6.0版本开始,支持形如nginx.*的通配符名字。 -从0.3.18版本开始,支持形如.nginx.org的特殊通配符名字。 +从0.3.18版本开始,支持形如.nginx.org的特殊通配符名字。 -从0.1.13版本开始,支持形如*.nginx.org的通配符名字。 +从0.1.13版本开始,支持形如*.nginx.org的通配符名字。 diff -r d40371689c1c -r 130fad6dc1b4 xml/en/docs/http/configuring_https_servers.xml --- a/xml/en/docs/http/configuring_https_servers.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/en/docs/http/configuring_https_servers.xml Thu Jul 19 05:17:45 2012 +0000 @@ -204,7 +204,7 @@ In this example the subject (“s”) of the -www.GoDaddy.com server certificate #0 is signed by an issuer +www.GoDaddy.com server certificate #0 is signed by an issuer (“i”) which itself is the subject of the certificate #1, which is signed by an issuer which itself is the subject of the certificate #2, which signed by the well-known issuer ValiCert, Inc. @@ -281,7 +281,7 @@ With this configuration a browser receives the certificate of the default -server, i.e., www.example.com regardless of the requested server name. +server, i.e., www.example.com regardless of the requested server name. This is caused by SSL protocol behaviour. The SSL connection is established before the browser sends an HTTP request and nginx does not know the name of the requested server. Therefore, it may only offer the certificate @@ -321,18 +321,18 @@ There are other ways to share a single IP address between several HTTPS servers, however, all of them have drawbacks. One way is to use a certificate with several names in -the SubjectAltName certificate field, for example, www.example.com -and www.example.org. +the SubjectAltName certificate field, for example, www.example.com +and www.example.org. However, the SubjectAltName field length is limited. Another way is to use a certificate with a wildcard name, for example, -*.example.org. This certificate matches -www.example.org, but does not match example.org -and www.sub.example.org. These two methods can also be combined. +*.example.org. This certificate matches +www.example.org, but does not match example.org +and www.sub.example.org. These two methods can also be combined. A certificate may contain exact and wildcard names in the SubjectAltName field, -for example, example.org and *.example.org. +for example, example.org and *.example.org. diff -r d40371689c1c -r 130fad6dc1b4 xml/en/docs/http/converting_rewrite_rules.xml --- a/xml/en/docs/http/converting_rewrite_rules.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/en/docs/http/converting_rewrite_rules.xml Thu Jul 19 05:17:45 2012 +0000 @@ -39,7 +39,7 @@ This is a wrong, cumbersome, and ineffective way. -The right way is to define a separate server for example.org: +The right way is to define a separate server for example.org: server { @@ -72,7 +72,7 @@ Another example. Instead of the “upside-down” logic “all that is not -example.com and is not www.example.com”: +example.com and is not www.example.com”: RewriteCond %{HTTP_HOST} !example.com @@ -80,7 +80,7 @@ RewriteRule (.*) http://www.example.com$1 -one should simply define example.com, www.example.com, +one should simply define example.com, www.example.com, and “everything else”: diff -r d40371689c1c -r 130fad6dc1b4 xml/en/docs/http/request_processing.xml --- a/xml/en/docs/http/request_processing.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/en/docs/http/request_processing.xml Thu Jul 19 05:17:45 2012 +0000 @@ -140,10 +140,10 @@ the IP address and port. If the server name is not found, the request will be processed by the default server. -For example, a request for www.example.com received on +For example, a request for www.example.com received on the 192.168.1.1:80 port will be handled by the default server of the 192.168.1.1:80 port, i.e., by the first server, -since there is no www.example.com defined for this port. +since there is no www.example.com defined for this port. diff -r d40371689c1c -r 130fad6dc1b4 xml/en/docs/http/server_names.xml --- a/xml/en/docs/http/server_names.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/en/docs/http/server_names.xml Thu Jul 19 05:17:45 2012 +0000 @@ -58,12 +58,12 @@ -wildcard names starting with an asterisk: *.example.org +wildcard names starting with an asterisk: *.example.org (longest first); -wildcard names ending with an asterisk: mail.* +wildcard names ending with an asterisk: mail.* (longest first); @@ -90,7 +90,7 @@ “~^w.*\.example\.org$”. An asterisk can match several name parts. The name “*.example.org” matches not only -www.example.org but www.sub.example.org as well. +www.example.org but www.sub.example.org as well. @@ -329,7 +329,7 @@ For these reasons, it is better to use exact names where possible. For example, if the most frequently requested names of a server -are example.org and www.example.org, +are example.org and www.example.org, it is more efficient to define them explicitly: @@ -441,15 +441,15 @@ -Wildcard form example.* has been supported since 0.6.0. +Wildcard form example.* has been supported since 0.6.0. -The special form .example.org has been supported since 0.3.18. +The special form .example.org has been supported since 0.3.18. -Wildcard form *.example.org has been supported since 0.1.13. +Wildcard form *.example.org has been supported since 0.1.13. diff -r d40371689c1c -r 130fad6dc1b4 xml/he/docs/http/converting_rewrite_rules.xml --- a/xml/he/docs/http/converting_rewrite_rules.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/he/docs/http/converting_rewrite_rules.xml Thu Jul 19 05:17:45 2012 +0000 @@ -34,7 +34,7 @@ צורה זו היא שגוייה, מסובכת, ולא יעילה. -הדרך הנכונה היא להגדיר שרת נפרד עבור example.org: +הדרך הנכונה היא להגדיר שרת נפרד עבור example.org: server { @@ -58,7 +58,7 @@ דוגמה נוספת, במקום הגיון הפוך: כל מה שהוא לא -example.com וגם לא www.example.com: +example.com וגם לא www.example.com: RewriteCond %{HTTP_HOST} !example.com @@ -66,7 +66,7 @@ RewriteRule (.*) http://www.example.com$1 -עלייך רק להגדיר את example.com, www.example.com, +עלייך רק להגדיר את example.com, www.example.com, וכל דבר אחר: diff -r d40371689c1c -r 130fad6dc1b4 xml/he/docs/http/server_names.xml --- a/xml/he/docs/http/server_names.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/he/docs/http/server_names.xml Thu Jul 19 05:17:45 2012 +0000 @@ -49,11 +49,11 @@ -שמות Wildcard המתחילים בכוכבית: *.example.org; +שמות Wildcard המתחילים בכוכבית: *.example.org; -שמות Wildcard המסתיימים בכוכבית: mail.*; +שמות Wildcard המסתיימים בכוכבית: mail.*; @@ -79,7 +79,7 @@ ~^w.*\.example\.org$. סימן הכוכבית יכול להחליף מספר חלקי שם. השם *.example.org מתאים לא רק ל -www.example.org אלא גם ל www.sub.example.org. +www.example.org אלא גם ל www.sub.example.org. @@ -252,9 +252,9 @@ זוהי תכונה של המאפיין listen ולא של המאפיין server_name. ראו גם “”. -באפשרותכם להגדיר שרתים המאזינים על פורטים *:80 ו *:8080, +באפשרותכם להגדיר שרתים המאזינים על פורטים *:80 ו *:8080, ולהגדיר שרת אחת שהוא ברירת המחדל עבור פורט - *:8080, בעוד שהשני יהיה ברירת מחדל עבור פורט *:80: + *:8080, בעוד שהשני יהיה ברירת מחדל עבור פורט *:80: server { @@ -302,7 +302,7 @@ בהתחשב בנסיבות אלה, הכי טוב להשתמש בשמות מדוייקים בכל מקום שהדבר אפשרי. -לדוגמה, אם השמות הנפוצים ביותר לשרת הם example.org ו www.example.org, +לדוגמה, אם השמות הנפוצים ביותר לשרת הם example.org ו www.example.org, יותר יעיל להגדיר אותם באופן מפורש: @@ -400,15 +400,15 @@ -צורות Wildcard מסוג example.* נתמכו החל מגירסה 0.6.0. +צורות Wildcard מסוג example.* נתמכו החל מגירסה 0.6.0. -הצורה המיוחדת .example.org נתמכה החל מגירסה 0.3.18. +הצורה המיוחדת .example.org נתמכה החל מגירסה 0.3.18. -הצורה *.example.org נתמכה החל מגירסה 0.1.13. +הצורה *.example.org נתמכה החל מגירסה 0.1.13. diff -r d40371689c1c -r 130fad6dc1b4 xml/ja/docs/http/configuring_https_servers.xml --- a/xml/ja/docs/http/configuring_https_servers.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ja/docs/http/configuring_https_servers.xml Thu Jul 19 05:17:45 2012 +0000 @@ -133,7 +133,7 @@ ... -この例では、www.GoDaddy.com サーバ証明書 #0 の対象 (“s”) はそれ自身が証明書 #1 の対象である発行者 (“i”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である ValiCert, Inc. によって署名されていて、ValiCert, Inc. の証明書はブラウザに組み込まれている証明書ベースに保持されています(こうして連鎖します)。 +この例では、www.GoDaddy.com サーバ証明書 #0 の対象 (“s”) はそれ自身が証明書 #1 の対象である発行者 (“i”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である ValiCert, Inc. によって署名されていて、ValiCert, Inc. の証明書はブラウザに組み込まれている証明書ベースに保持されています(こうして連鎖します)。 @@ -193,7 +193,7 @@ } -この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは www.example.com の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 +この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは www.example.com の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 @@ -225,11 +225,11 @@ name="複数サーバ名をもつ SSL 証明書"> -単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名(例えば、www.example.comwww.example.org)をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 +単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名(例えば、www.example.comwww.example.org)をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 -もうひとつの方法は、例えば *.example.org のようにワイルドカード名を持った証明書を使用する方法です。この証明書は www.example.org にマッチしますが example.orgwww.sub.example.org にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば example.org*.example.org のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 +もうひとつの方法は、例えば *.example.org のようにワイルドカード名を持った証明書を使用する方法です。この証明書は www.example.org にマッチしますが example.orgwww.sub.example.org にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば example.org*.example.org のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 diff -r d40371689c1c -r 130fad6dc1b4 xml/ja/docs/http/converting_rewrite_rules.xml --- a/xml/ja/docs/http/converting_rewrite_rules.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ja/docs/http/converting_rewrite_rules.xml Thu Jul 19 05:17:45 2012 +0000 @@ -29,7 +29,7 @@ -これは間違っていて面倒で非効率的な方法です。正しい方法は example.org 用に別のサーバを定義します: +これは間違っていて面倒で非効率的な方法です。正しい方法は example.org 用に別のサーバを定義します: server { @@ -52,7 +52,7 @@
-別の例として、example.com 以外と www.example.com 以外のすべて、という後方ロジックの代わりの例です: +別の例として、example.com 以外と www.example.com 以外のすべて、という後方ロジックの代わりの例です: RewriteCond %{HTTP_HOST} !example.com @@ -60,7 +60,7 @@ RewriteRule (.*) http://www.example.com$1 -この場合、単に example.comwww.example.com、そしてそれ以外を定義します: +この場合、単に example.comwww.example.com、そしてそれ以外を定義します: diff -r d40371689c1c -r 130fad6dc1b4 xml/ja/docs/http/request_processing.xml --- a/xml/ja/docs/http/request_processing.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ja/docs/http/request_processing.xml Thu Jul 19 05:17:45 2012 +0000 @@ -101,7 +101,7 @@ この設定では、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 は定義されていないからです。 +もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、192.168.1.1:80 ポートで受信された www.example.com へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは www.example.com は定義されていないからです。 diff -r d40371689c1c -r 130fad6dc1b4 xml/ja/docs/http/server_names.xml --- a/xml/ja/docs/http/server_names.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ja/docs/http/server_names.xml Thu Jul 19 05:17:45 2012 +0000 @@ -46,11 +46,11 @@ -アスタリスクで始まるワイルドカード名: *.example.org +アスタリスクで始まるワイルドカード名: *.example.org -アスタリスクで終わるワイルドカード名: mail.* +アスタリスクで終わるワイルドカード名: mail.* @@ -68,7 +68,7 @@ name="ワイルドカード名"> -ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 www.*.example.orgw*.example.org は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば ~^www\..+\.example\.org$~^w.*\.example\.org$ として指定することができます。アスタリスクは複数部分にマッチさせることができます。*.example.orgwww.example.org だけでなく www.sub.example.org にもマッチします。 +ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 www.*.example.orgw*.example.org は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば ~^www\..+\.example\.org$~^w.*\.example\.org$ として指定することができます。アスタリスクは複数部分にマッチさせることができます。*.example.orgwww.example.org だけでなく www.sub.example.org にもマッチします。 @@ -245,7 +245,7 @@ -これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が example.orgwww.example.org だとすると、これらを明示的に定義するとより効率的です: +これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が example.orgwww.example.org だとすると、これらを明示的に定義するとより効率的です: server { @@ -331,15 +331,15 @@ -ワイルドカードの形式 example.* のサポートは 0.6.0 からです。 +ワイルドカードの形式 example.* のサポートは 0.6.0 からです。 -特別な形式 .example.org のサポートは 0.3.18 からです。 +特別な形式 .example.org のサポートは 0.3.18 からです。 -ワイルドカードの形式 *.example.org のサポートは 0.1.13 からです。 +ワイルドカードの形式 *.example.org のサポートは 0.1.13 からです。 diff -r d40371689c1c -r 130fad6dc1b4 xml/ru/docs/http/configuring_https_servers.xml --- a/xml/ru/docs/http/configuring_https_servers.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ru/docs/http/configuring_https_servers.xml Thu Jul 19 05:17:45 2012 +0000 @@ -204,7 +204,7 @@ В этом примере субъект (“s”) сертификата №0 сервера -www.GoDaddy.com подписан издателем (“i”), +www.GoDaddy.com подписан издателем (“i”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем ValiCert, Inc., @@ -282,7 +282,7 @@ В такой конфигурации браузер получит сертификат первого сервера, т.е. -www.example.com, независимо от запрашиваемого имени сервера. +www.example.com, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и nginx не знает имени запрашиваемого сервера. @@ -323,21 +323,21 @@ IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими -именами в поле SubjectAltName сертификата, например www.example.comwww.example.org. +именами в поле SubjectAltName сертификата, например www.example.comwww.example.org. Однако, длина поля SubjectAltName ограничена. Другим способом является использование wildcard-сертификата, например -*.example.org. +*.example.org. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. -Под такой сертификат подходит www.example.org, но не подходят -example.org и www.sub.example.org. +Под такой сертификат подходит www.example.org, но не подходят +example.org и www.sub.example.org. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле -SubjectAltName, например example.org и *.example.org. +SubjectAltName, например example.org и *.example.org. diff -r d40371689c1c -r 130fad6dc1b4 xml/ru/docs/http/request_processing.xml --- a/xml/ru/docs/http/request_processing.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/ru/docs/http/request_processing.xml Thu Jul 19 05:17:45 2012 +0000 @@ -139,10 +139,10 @@ которые соответствуют IP-адресу и порту. Если имя сервера не найдено, запрос будет обработан в сервере по умолчанию. -Например, запрос www.example.com, пришедший на порт +Например, запрос www.example.com, пришедший на порт 192.168.1.1:80, будет обработан сервером по умолчанию для порта 192.168.1.1:80, т.е. первым сервером, т.к. для этого порта -www.example.com не указан в списке имён серверов. +www.example.com не указан в списке имён серверов. diff -r d40371689c1c -r 130fad6dc1b4 xml/tr/docs/http/configuring_https_servers.xml --- a/xml/tr/docs/http/configuring_https_servers.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/tr/docs/http/configuring_https_servers.xml Thu Jul 19 05:17:45 2012 +0000 @@ -134,7 +134,7 @@ ... -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. +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. @@ -194,7 +194,7 @@ } -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 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. @@ -226,11 +226,11 @@ name="Birçok ad içeren SSL sertifikası"> -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. +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. +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. diff -r d40371689c1c -r 130fad6dc1b4 xml/tr/docs/http/converting_rewrite_rules.xml --- a/xml/tr/docs/http/converting_rewrite_rules.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/tr/docs/http/converting_rewrite_rules.xml Thu Jul 19 05:17:45 2012 +0000 @@ -52,7 +52,7 @@
-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): +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 @@ -60,7 +60,7 @@ RewriteRule (.*) http://www.example.com$1 -sadece example.com, www.example.com ve diğer her şeyi ayrı ayrı tanımlamalısınız: +sadece example.com, www.example.com ve diğer her şeyi ayrı ayrı tanımlamalısınız: server { diff -r d40371689c1c -r 130fad6dc1b4 xml/tr/docs/http/request_processing.xml --- a/xml/tr/docs/http/request_processing.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/tr/docs/http/request_processing.xml Thu Jul 19 05:17:45 2012 +0000 @@ -106,7 +106,7 @@ 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. +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. diff -r d40371689c1c -r 130fad6dc1b4 xml/tr/docs/http/server_names.xml --- a/xml/tr/docs/http/server_names.xml Thu Jul 19 04:57:51 2012 +0000 +++ b/xml/tr/docs/http/server_names.xml Thu Jul 19 05:17:45 2012 +0000 @@ -46,11 +46,11 @@ -* ile başlayan wildcard adlar: *.example.org; +* ile başlayan wildcard adlar: *.example.org; -* ile biten wildcard adlar: mail.*; +* ile biten wildcard adlar: mail.*; @@ -68,7 +68,7 @@ name="Wildcard adlar"> -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. +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. @@ -252,7 +252,7 @@ -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: +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 { @@ -335,15 +335,15 @@ -example.* wildcard formu 0.6.0 versiyonundan beri destekleniyor. +example.* wildcard formu 0.6.0 versiyonundan beri destekleniyor. -.example.org özel formu 0.3.18 versiyonundan beri destekleniyor. +.example.org özel formu 0.3.18 versiyonundan beri destekleniyor. -*.example.org wildcard formu 0.1.13 versiyonundan beri destekleniyor. +*.example.org wildcard formu 0.1.13 versiyonundan beri destekleniyor.