Mercurial > hg > nginx-site
changeset 593:130fad6dc1b4
Replaced the uses of "url" element with "literal".
line wrap: on
line diff
--- 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 @@ } </programlisting> -使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机的证书，比方说就是<url>www.nginx.com</url>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后，才能发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。 +使用上面的配置，不论浏览器请求哪个主机，都只会收到默认主机的证书，比方说就是<literal>www.nginx.com</literal>。这是由SSL协议本身的行为引起的。因为SSL规定在建立SSL连接以后，才能发送HTTP请求，所以nginx建立SSL连接时不知道所请求主机的名字，因此，它只会返回默认主机的证书。 </para> <para> @@ -234,11 +234,11 @@ name="带有多个主机名的SSL证书"> <para> -也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如<url>www.nginx.com</url>和<url>www.nginx.org</url>。这种方法的限制是“SubjectAltName”字段的长度。 +也有其他一些方法可以实现多个HTTPS主机共享一个IP地址，但都有不足。其中一种方法是使用在“SubjectAltName”字段中存放多个名字的证书，比如<literal>www.nginx.com</literal>和<literal>www.nginx.org</literal>。这种方法的限制是“SubjectAltName”字段的长度。 </para> <para> -另一种方式是使用主机名中含有通配符的证书，比如<url>*.nginx.org</url>。这个证书匹配<url>www.nginx.org</url>，但是不匹配<url>nginx.org</url>和<url>www.sub.nginx.org</url>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如<url>nginx.org</url>和<url>*.nginx.org</url>。 +另一种方式是使用主机名中含有通配符的证书，比如<literal>*.nginx.org</literal>。这个证书匹配<literal>www.nginx.org</literal>，但是不匹配<literal>nginx.org</literal>和<literal>www.sub.nginx.org</literal>。这两种方法可以结合在一起——使用在“SubjectAltName”字段中存放的多个名字的证书，这些名字既可以是确切的名字，也可以是通配符，比如<literal>nginx.org</literal>和<literal>*.nginx.org</literal>。 </para> <para>
--- 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 @@ </para> <para> -这种做法是错的，复杂而且低效。正确的方式是为<url>nginx.org</url>定义一个单独的服务器： +这种做法是错的，复杂而且低效。正确的方式是为<literal>nginx.org</literal>定义一个单独的服务器： <programlisting> server { @@ -61,7 +61,7 @@ <section> <para> -再举一个例子，处理一个和刚才相反的逻辑：既不是来自<url>nginx.com</url>，又不是来自<url>www.nginx.com</url>： +再举一个例子，处理一个和刚才相反的逻辑：既不是来自<literal>nginx.com</literal>，又不是来自<literal>www.nginx.com</literal>： <programlisting> RewriteCond %{HTTP_HOST} !nginx.com @@ -69,7 +69,7 @@ RewriteRule (.*) http://www.nginx.com$1 </programlisting> -应该按下面这样分开定义<url>nginx.com</url>、<url>www.nginx.com</url>和其他站点： +应该按下面这样分开定义<literal>nginx.com</literal>、<literal>www.nginx.com</literal>和其他站点： <programlisting> server {
--- 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 @@ } </programlisting> -这个配置中，nginx根据"<literal>server</literal>"配置块中的"<literal>listen</literal>"指令首先测试请求的IP地址和端口是否匹配某个定义的值。如果匹配成功，则继续测试请求的Host头是否匹配这个块中的"<literal>server_name</literal>"的值。如果主机名匹配失败，这个请求将被交给默认的虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问<url>www.nginx.com</url>的请求将被监听192.168.1.1:80端口的默认服务器处理，本例中就是第一个服务器，因为这个端口上没有定义域名为<url>www.nginx.com</url>的服务器。 +这个配置中，nginx根据"<literal>server</literal>"配置块中的"<literal>listen</literal>"指令首先测试请求的IP地址和端口是否匹配某个定义的值。如果匹配成功，则继续测试请求的Host头是否匹配这个块中的"<literal>server_name</literal>"的值。如果主机名匹配失败，这个请求将被交给默认的虚拟主机处理。例如，一个从192.168.1.1:80端口收到的访问<literal>www.nginx.com</literal>的请求将被监听192.168.1.1:80端口的默认服务器处理，本例中就是第一个服务器，因为这个端口上没有定义域名为<literal>www.nginx.com</literal>的服务器。 </para> <para>
--- 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 @@ </listitem> <listitem> -以星号起始的通配符名字：<url>*.nginx.org</url>； +以星号起始的通配符名字：<literal>*.nginx.org</literal>； </listitem> <listitem> -以星号结束的通配符名字：<url>mail.*</url>； +以星号结束的通配符名字：<literal>mail.*</literal>； </listitem> <listitem> @@ -70,7 +70,7 @@ name="通配符名字"> <para> -通配符名字只可以在名字的起始处或结尾处包含一个星号，并且星号与其他字符之间用点分隔。所以，<literal>www.*.nginx.org</literal>和<literal>w*.nginx.org</literal>都是非法的。不过，上面的两个名字可以使用正则表达式描述：<literal>~^www\..+\.nginx\.org$</literal>和<literal>~^w.*\.nginx\.org$</literal>。星号可以匹配名字的多个节（各节都是以点号分隔的），比如<literal>*.nginx.org</literal>不仅匹配<url>www.nginx.org</url>，也匹配<url>www.sub.nginx.org</url>。 +通配符名字只可以在名字的起始处或结尾处包含一个星号，并且星号与其他字符之间用点分隔。所以，<literal>www.*.nginx.org</literal>和<literal>w*.nginx.org</literal>都是非法的。不过，上面的两个名字可以使用正则表达式描述：<literal>~^www\..+\.nginx\.org$</literal>和<literal>~^w.*\.nginx\.org$</literal>。星号可以匹配名字的多个节（各节都是以点号分隔的），比如<literal>*.nginx.org</literal>不仅匹配<literal>www.nginx.org</literal>，也匹配<literal>www.sub.nginx.org</literal>。 </para> <para> @@ -244,7 +244,7 @@ </para> <para> -鉴于以上原因，请尽可能使用确切的名字。举个例子，如果使用<url>nginx.org</url>和<url>www.nginx.org</url>来访问服务器是最频繁的，那么将它们明确的定义出来就更为有效： +鉴于以上原因，请尽可能使用确切的名字。举个例子，如果使用<literal>nginx.org</literal>和<literal>www.nginx.org</literal>来访问服务器是最频繁的，那么将它们明确的定义出来就更为有效： <programlisting> server { @@ -329,15 +329,15 @@ </listitem> <listitem> -从0.6.0版本开始，支持形如<url>nginx.*</url>的通配符名字。 +从0.6.0版本开始，支持形如<literal>nginx.*</literal>的通配符名字。 </listitem> <listitem> -从0.3.18版本开始，支持形如<url>.nginx.org</url>的特殊通配符名字。 +从0.3.18版本开始，支持形如<literal>.nginx.org</literal>的特殊通配符名字。 </listitem> <listitem> -从0.1.13版本开始，支持形如<url>*.nginx.org</url>的通配符名字。 +从0.1.13版本开始，支持形如<literal>*.nginx.org</literal>的通配符名字。 </listitem> </list>
--- 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 @@ </programlisting> In this example the subject (“<i>s</i>”) of the -<url>www.GoDaddy.com</url> server certificate #0 is signed by an issuer +<literal>www.GoDaddy.com</literal> server certificate #0 is signed by an issuer (“<i>i</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 <i>ValiCert, Inc.</i> @@ -281,7 +281,7 @@ </programlisting> With this configuration a browser receives the certificate of the default -server, i.e., <url>www.example.com</url> regardless of the requested server name. +server, i.e., <literal>www.example.com</literal> 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, <url>www.example.com</url> -and <url>www.example.org</url>. +the SubjectAltName certificate field, for example, <literal>www.example.com</literal> +and <literal>www.example.org</literal>. However, the SubjectAltName field length is limited. </para> <para> Another way is to use a certificate with a wildcard name, for example, -<url>*.example.org</url>. This certificate matches -<url>www.example.org</url>, but does not match <url>example.org</url> -and <url>www.sub.example.org</url>. These two methods can also be combined. +<literal>*.example.org</literal>. This certificate matches +<literal>www.example.org</literal>, but does not match <literal>example.org</literal> +and <literal>www.sub.example.org</literal>. These two methods can also be combined. A certificate may contain exact and wildcard names in the SubjectAltName field, -for example, <url>example.org</url> and <url>*.example.org</url>. +for example, <literal>example.org</literal> and <literal>*.example.org</literal>. </para> <para>
--- 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 @@ <para> This is a wrong, cumbersome, and ineffective way. -The right way is to define a separate server for <url>example.org</url>: +The right way is to define a separate server for <literal>example.org</literal>: <programlisting> server { @@ -72,7 +72,7 @@ <para> Another example. Instead of the “upside-down” logic “all that is not -<url>example.com</url> and is not <url>www.example.com</url>”: +<literal>example.com</literal> and is not <literal>www.example.com</literal>”: <programlisting> RewriteCond %{HTTP_HOST} !example.com @@ -80,7 +80,7 @@ RewriteRule (.*) http://www.example.com$1 </programlisting> -one should simply define <url>example.com</url>, <url>www.example.com</url>, +one should simply define <literal>example.com</literal>, <literal>www.example.com</literal>, and “everything else”: <programlisting>
--- 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 <url>www.example.com</url> received on +For example, a request for <literal>www.example.com</literal> 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 <url>www.example.com</url> defined for this port. +since there is no <literal>www.example.com</literal> defined for this port. </para> <para>
--- 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 @@ </listitem> <listitem> -wildcard names starting with an asterisk: <url>*.example.org</url> +wildcard names starting with an asterisk: <literal>*.example.org</literal> (longest first); </listitem> <listitem> -wildcard names ending with an asterisk: <url>mail.*</url> +wildcard names ending with an asterisk: <literal>mail.*</literal> (longest first); </listitem> @@ -90,7 +90,7 @@ “<literal>~^w.*\.example\.org$</literal>”. An asterisk can match several name parts. The name “<literal>*.example.org</literal>” matches not only -<url>www.example.org</url> but <url>www.sub.example.org</url> as well. +<literal>www.example.org</literal> but <literal>www.sub.example.org</literal> as well. </para> <para> @@ -329,7 +329,7 @@ <para> For these reasons, it is better to use exact names where possible. For example, if the most frequently requested names of a server -are <url>example.org</url> and <url>www.example.org</url>, +are <literal>example.org</literal> and <literal>www.example.org</literal>, it is more efficient to define them explicitly: <programlisting> @@ -441,15 +441,15 @@ </listitem> <listitem> -Wildcard form <url>example.*</url> has been supported since 0.6.0. +Wildcard form <literal>example.*</literal> has been supported since 0.6.0. </listitem> <listitem> -The special form <url>.example.org</url> has been supported since 0.3.18. +The special form <literal>.example.org</literal> has been supported since 0.3.18. </listitem> <listitem> -Wildcard form <url>*.example.org</url> has been supported since 0.1.13. +Wildcard form <literal>*.example.org</literal> has been supported since 0.1.13. </listitem> </list>
--- 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 @@ <para> צורה זו היא שגוייה, מסובכת, ולא יעילה. -הדרך הנכונה היא להגדיר שרת נפרד עבור <url>example.org</url>: +הדרך הנכונה היא להגדיר שרת נפרד עבור <literal>example.org</literal>: <programlisting> server { @@ -58,7 +58,7 @@ <para> דוגמה נוספת, במקום הגיון הפוך: כל מה שהוא לא -<url>example.com</url> וגם לא <url>www.example.com</url>: +<literal>example.com</literal> וגם לא <literal>www.example.com</literal>: <programlisting> RewriteCond %{HTTP_HOST} !example.com @@ -66,7 +66,7 @@ RewriteRule (.*) http://www.example.com$1 </programlisting> -עלייך רק להגדיר את <url>example.com</url>, <url>www.example.com</url>, +עלייך רק להגדיר את <literal>example.com</literal>, <literal>www.example.com</literal>, וכל דבר אחר: <programlisting>
--- 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 @@ </listitem> <listitem> -שמות Wildcard המתחילים בכוכבית: <url>*.example.org</url>; +שמות Wildcard המתחילים בכוכבית: <literal>*.example.org</literal>; </listitem> <listitem> -שמות Wildcard המסתיימים בכוכבית: <url>mail.*</url>; +שמות Wildcard המסתיימים בכוכבית: <literal>mail.*</literal>; </listitem> <listitem> @@ -79,7 +79,7 @@ <literal>~^w.*\.example\.org$</literal>. סימן הכוכבית יכול להחליף מספר חלקי שם. השם <literal>*.example.org</literal> מתאים לא רק ל -<url>www.example.org</url> אלא גם ל <url>www.sub.example.org</url>. +<literal>www.example.org</literal> אלא גם ל <literal>www.sub.example.org</literal>. </para> <para> @@ -252,9 +252,9 @@ זוהי תכונה של המאפיין <literal>listen</literal> ולא של המאפיין <literal>server_name</literal>. ראו גם “<link doc="../../../en/docs/http/request_processing.xml" />”. -באפשרותכם להגדיר שרתים המאזינים על פורטים <url>*:80</url> ו <url>*:8080</url>, +באפשרותכם להגדיר שרתים המאזינים על פורטים <literal>*:80</literal> ו <literal>*:8080</literal>, ולהגדיר שרת אחת שהוא ברירת המחדל עבור פורט - <url>*:8080</url>, בעוד שהשני יהיה ברירת מחדל עבור פורט <url>*:80</url>: + <literal>*:8080</literal>, בעוד שהשני יהיה ברירת מחדל עבור פורט <literal>*:80</literal>: <programlisting> server { @@ -302,7 +302,7 @@ <para> בהתחשב בנסיבות אלה, הכי טוב להשתמש בשמות מדוייקים בכל מקום שהדבר אפשרי. -לדוגמה, אם השמות הנפוצים ביותר לשרת הם <url>example.org</url> ו <url>www.example.org</url>, +לדוגמה, אם השמות הנפוצים ביותר לשרת הם <literal>example.org</literal> ו <literal>www.example.org</literal>, יותר יעיל להגדיר אותם באופן מפורש: <programlisting> @@ -400,15 +400,15 @@ </listitem> <listitem> -צורות Wildcard מסוג <url>example.*</url> נתמכו החל מגירסה 0.6.0. +צורות Wildcard מסוג <literal>example.*</literal> נתמכו החל מגירסה 0.6.0. </listitem> <listitem> -הצורה המיוחדת <url>.example.org</url> נתמכה החל מגירסה 0.3.18. +הצורה המיוחדת <literal>.example.org</literal> נתמכה החל מגירסה 0.3.18. </listitem> <listitem> -הצורה <url>*.example.org</url> נתמכה החל מגירסה 0.1.13. +הצורה <literal>*.example.org</literal> נתמכה החל מגירסה 0.1.13. </listitem> </list>
--- 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 @@ ... </programlisting> -この例では、<url>www.GoDaddy.com</url> サーバ証明書 #0 の対象 (“<i>s</i>”) はそれ自身が証明書 #1 の対象である発行者 (“<i>i</i>”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である <i>ValiCert, Inc.</i> によって署名されていて、<i>ValiCert, Inc.</i> の証明書はブラウザに組み込まれている証明書ベースに保持されています（こうして連鎖します）。 +この例では、<literal>www.GoDaddy.com</literal> サーバ証明書 #0 の対象 (“<i>s</i>”) はそれ自身が証明書 #1 の対象である発行者 (“<i>i</i>”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である <i>ValiCert, Inc.</i> によって署名されていて、<i>ValiCert, Inc.</i> の証明書はブラウザに組み込まれている証明書ベースに保持されています（こうして連鎖します）。 </para> <para> @@ -193,7 +193,7 @@ } </programlisting> -この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは <url>www.example.com</url> の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 +この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは <literal>www.example.com</literal> の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 </para> <para> @@ -225,11 +225,11 @@ name="複数サーバ名をもつ SSL 証明書"> <para> -単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<url>www.example.com</url> と <url>www.example.org</url>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 +単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<literal>www.example.com</literal> と <literal>www.example.org</literal>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 </para> <para> -もうひとつの方法は、例えば <url>*.example.org</url> のようにワイルドカード名を持った証明書を使用する方法です。この証明書は <url>www.example.org</url> にマッチしますが <url>example.org</url> や <url>www.sub.example.org</url> にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば <url>example.org</url> と <url>*.example.org</url> のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 +もうひとつの方法は、例えば <literal>*.example.org</literal> のようにワイルドカード名を持った証明書を使用する方法です。この証明書は <literal>www.example.org</literal> にマッチしますが <literal>example.org</literal> や <literal>www.sub.example.org</literal> にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば <literal>example.org</literal> と <literal>*.example.org</literal> のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 </para> <para>
--- 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 @@ </para> <para> -これは間違っていて面倒で非効率的な方法です。正しい方法は <url>example.org</url> 用に別のサーバを定義します: +これは間違っていて面倒で非効率的な方法です。正しい方法は <literal>example.org</literal> 用に別のサーバを定義します: <programlisting> server { @@ -52,7 +52,7 @@ <section> <para> -別の例として、<url>example.com</url> 以外と <url>www.example.com</url> 以外のすべて、という後方ロジックの代わりの例です: +別の例として、<literal>example.com</literal> 以外と <literal>www.example.com</literal> 以外のすべて、という後方ロジックの代わりの例です: <programlisting> RewriteCond %{HTTP_HOST} !example.com @@ -60,7 +60,7 @@ RewriteRule (.*) http://www.example.com$1 </programlisting> -この場合、単に <url>example.com</url>、<url>www.example.com</url>、そしてそれ以外を定義します: +この場合、単に <literal>example.com</literal>、<literal>www.example.com</literal>、そしてそれ以外を定義します: <programlisting>
--- 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 はまず最初に <literal>server</literal> ブロックの <literal>listen</literal> ディレクティブに対してリクエストの IP アドレスとポートを考査します。次に、その IP アドレスとポートにマッチする <literal>server</literal> ブロックの <literal>server_name</literal> ディレクティブに対して、その HTTP リクエストの “Host” ヘッダを考査します。 -もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、192.168.1.1:80 ポートで受信された <url>www.example.com</url> へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは <url>www.example.com</url> は定義されていないからです。 +もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、192.168.1.1:80 ポートで受信された <literal>www.example.com</literal> へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは <literal>www.example.com</literal> は定義されていないからです。 </para> <para>
--- 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 @@ </listitem> <listitem> -アスタリスクで始まるワイルドカード名: <url>*.example.org</url> +アスタリスクで始まるワイルドカード名: <literal>*.example.org</literal> </listitem> <listitem> -アスタリスクで終わるワイルドカード名: <url>mail.*</url> +アスタリスクで終わるワイルドカード名: <literal>mail.*</literal> </listitem> <listitem> @@ -68,7 +68,7 @@ name="ワイルドカード名"> <para> -ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 <literal>www.*.example.org</literal> や <literal>w*.example.org</literal> は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば <literal>~^www\..+\.example\.org$</literal> や <literal>~^w.*\.example\.org$</literal> として指定することができます。アスタリスクは複数部分にマッチさせることができます。<literal>*.example.org</literal> は <url>www.example.org</url> だけでなく <url>www.sub.example.org</url> にもマッチします。 +ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 <literal>www.*.example.org</literal> や <literal>w*.example.org</literal> は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば <literal>~^www\..+\.example\.org$</literal> や <literal>~^w.*\.example\.org$</literal> として指定することができます。アスタリスクは複数部分にマッチさせることができます。<literal>*.example.org</literal> は <literal>www.example.org</literal> だけでなく <literal>www.sub.example.org</literal> にもマッチします。 </para> <para> @@ -245,7 +245,7 @@ </para> <para> -これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が <url>example.org</url> と <url>www.example.org</url> だとすると、これらを明示的に定義するとより効率的です: +これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が <literal>example.org</literal> と <literal>www.example.org</literal> だとすると、これらを明示的に定義するとより効率的です: <programlisting> server { @@ -331,15 +331,15 @@ </listitem> <listitem> -ワイルドカードの形式 <url>example.*</url> のサポートは 0.6.0 からです。 +ワイルドカードの形式 <literal>example.*</literal> のサポートは 0.6.0 からです。 </listitem> <listitem> -特別な形式 <url>.example.org</url> のサポートは 0.3.18 からです。 +特別な形式 <literal>.example.org</literal> のサポートは 0.3.18 からです。 </listitem> <listitem> -ワイルドカードの形式 <url>*.example.org</url> のサポートは 0.1.13 からです。 +ワイルドカードの形式 <literal>*.example.org</literal> のサポートは 0.1.13 からです。 </listitem> </list>
--- 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 @@ </programlisting> В этом примере субъект (“<i>s</i>”) сертификата №0 сервера -<url>www.GoDaddy.com</url> подписан издателем (“<i>i</i>”), +<literal>www.GoDaddy.com</literal> подписан издателем (“<i>i</i>”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем <i>ValiCert, Inc.</i>, @@ -282,7 +282,7 @@ </programlisting> В такой конфигурации браузер получит сертификат первого сервера, т.е. -<url>www.example.com</url>, независимо от запрашиваемого имени сервера. +<literal>www.example.com</literal>, независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и nginx не знает имени запрашиваемого сервера. @@ -323,21 +323,21 @@ IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими -именами в поле SubjectAltName сертификата, например <url>www.example.com</url> -и <url>www.example.org</url>. +именами в поле SubjectAltName сертификата, например <literal>www.example.com</literal> +и <literal>www.example.org</literal>. Однако, длина поля SubjectAltName ограничена. </para> <para> Другим способом является использование wildcard-сертификата, например -<url>*.example.org</url>. +<literal>*.example.org</literal>. Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. -Под такой сертификат подходит <url>www.example.org</url>, но не подходят -<url>example.org</url> и <url>www.sub.example.org</url>. +Под такой сертификат подходит <literal>www.example.org</literal>, но не подходят +<literal>example.org</literal> и <literal>www.sub.example.org</literal>. Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле -SubjectAltName, например <url>example.org</url> и <url>*.example.org</url>. +SubjectAltName, например <literal>example.org</literal> и <literal>*.example.org</literal>. </para> <para>
--- 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-адресу и порту. Если имя сервера не найдено, запрос будет обработан в сервере по умолчанию. -Например, запрос <url>www.example.com</url>, пришедший на порт +Например, запрос <literal>www.example.com</literal>, пришедший на порт 192.168.1.1:80, будет обработан сервером по умолчанию для порта 192.168.1.1:80, т.е. первым сервером, т.к. для этого порта -<url>www.example.com</url> не указан в списке имён серверов. +<literal>www.example.com</literal> не указан в списке имён серверов. </para> <para>
--- 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 @@ ... </programlisting> -Bu örnekte <url>www.GoDaddy.com</url> sunucu sertifikasının (server certificate #0) “<i>s</i>” ile belirtilen konusu (subject), “<i>i</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 <i>ValiCert, Inc.</i> tarafından imzalanmıştır. Bu firmanın sertifikası, tarayıcının kurulumuyla gelen sertifika veritabanında bulunur. +Bu örnekte <literal>www.GoDaddy.com</literal> sunucu sertifikasının (server certificate #0) “<i>s</i>” ile belirtilen konusu (subject), “<i>i</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 <i>ValiCert, Inc.</i> tarafından imzalanmıştır. Bu firmanın sertifikası, tarayıcının kurulumuyla gelen sertifika veritabanında bulunur. </para> <para> @@ -194,7 +194,7 @@ } </programlisting> -Bu yapılandırmada, bir tarayıcı talep edilen sunucuya bakmadan, varsayılan sunucunun sertifikasını alır, örneğin: <url>www.example.com</url>. 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: <literal>www.example.com</literal>. 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. </para> <para> @@ -226,11 +226,11 @@ name="Birçok ad içeren SSL sertifikası"> <para> -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: <url>www.example.com</url> ve <url>www.example.org</url>. 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: <literal>www.example.com</literal> ve <literal>www.example.org</literal>. Ancak SubjectAltName alan uzunluğu sınırlandırılmıştır. </para> <para> -Diğer bir yol ise bir sertifikayı bir wildcard adı ile birlikte kullanmaktır. Örneğin: <url>*.example.org</url>. Bu sertifika <url>www.example.org</url> ile eşleşir ancak <url>example.org</url> ve <url>www.sub.example.org</url> 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: <url>example.org</url> ve <url>*.example.org</url>. +Diğer bir yol ise bir sertifikayı bir wildcard adı ile birlikte kullanmaktır. Örneğin: <literal>*.example.org</literal>. Bu sertifika <literal>www.example.org</literal> ile eşleşir ancak <literal>example.org</literal> ve <literal>www.sub.example.org</literal> 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: <literal>example.org</literal> ve <literal>*.example.org</literal>. </para> <para>
--- 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 @@ <section> <para> -Diğer bir örnek ile aşağıdaki geri kalmış mantık yerine (<url>example.com</url> olmayan her şey ve <url>www.example.com</url> olmayan her şey): +Diğer bir örnek ile aşağıdaki geri kalmış mantık yerine (<literal>example.com</literal> olmayan her şey ve <literal>www.example.com</literal> olmayan her şey): <programlisting> RewriteCond %{HTTP_HOST} !example.com @@ -60,7 +60,7 @@ RewriteRule (.*) http://www.example.com$1 </programlisting> -sadece <url>example.com</url>, <url>www.example.com</url> ve diğer her şeyi ayrı ayrı tanımlamalısınız: +sadece <literal>example.com</literal>, <literal>www.example.com</literal> ve diğer her şeyi ayrı ayrı tanımlamalısınız: <programlisting> server {
--- 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 <literal>server</literal> bloklarında yer alan <literal>listen</literal> 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 <literal>server</literal> bloklarında yer alan <literal>server_name</literal> girdileri ile kontrol eder. -Eğer sunucu bulunamazsa varsayılan sunucu tarafından işlenir. Örneğin, <url>www.example.com</url> için 192.168.1.1:80 adres ve portuna gelen bir talep, eğer bu adres ve port için <url>www.example.com</url> 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, <literal>www.example.com</literal> için 192.168.1.1:80 adres ve portuna gelen bir talep, eğer bu adres ve port için <literal>www.example.com</literal> tanımlanmamışsa, 192.168.1.1:80’e ait varsayılan sunucu tarafından işlenir. </para> <para>
--- 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 @@ </listitem> <listitem> -* ile başlayan wildcard adlar: <url>*.example.org</url>; +* ile başlayan wildcard adlar: <literal>*.example.org</literal>; </listitem> <listitem> -* ile biten wildcard adlar: <url>mail.*</url>; +* ile biten wildcard adlar: <literal>mail.*</literal>; </listitem> <listitem> @@ -68,7 +68,7 @@ name="Wildcard adlar"> <para> -Bir wildcard ad ancak başlangıçta veya bitişte * ifadesini içerir ve nokta ile sınırlandırılır. <literal>www.*.example.org</literal> ve <literal>w*.example.org</literal> adları geçersizdir. Ancak bu adlar düzenli ifadeler ile geçerli hale getirilebilir, örneğin, <literal>~^www\..+\.example\.org$</literal> ve <literal>~^w.*\.example\.org$</literal>. Buradaki * bir çok eşleşmeyi tanımlayabilir. <literal>*.example.org</literal> ifadesi <url>www.example.org</url> ve <url>www.sub.example.org</url> 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. <literal>www.*.example.org</literal> ve <literal>w*.example.org</literal> adları geçersizdir. Ancak bu adlar düzenli ifadeler ile geçerli hale getirilebilir, örneğin, <literal>~^www\..+\.example\.org$</literal> ve <literal>~^w.*\.example\.org$</literal>. Buradaki * bir çok eşleşmeyi tanımlayabilir. <literal>*.example.org</literal> ifadesi <literal>www.example.org</literal> ve <literal>www.sub.example.org</literal> adlarına karşılık gelebilir. </para> <para> @@ -252,7 +252,7 @@ </para> <para> -Bu nedenlerden dolayı, imkanlar el veriyorsa gerçek adları kullanmak en iyisidir. Örneğin, bir sunucunun en sık talep edilen adları <url>example.org</url> ve <url>www.example.org</url> 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ı <literal>example.org</literal> ve <literal>www.example.org</literal> ise bunları açıkca belirtmek daha etkili olacaktır: <programlisting> server { @@ -335,15 +335,15 @@ </listitem> <listitem> -<url>example.*</url> wildcard formu 0.6.0 versiyonundan beri destekleniyor. +<literal>example.*</literal> wildcard formu 0.6.0 versiyonundan beri destekleniyor. </listitem> <listitem> -<url>.example.org</url> özel formu 0.3.18 versiyonundan beri destekleniyor. +<literal>.example.org</literal> özel formu 0.3.18 versiyonundan beri destekleniyor. </listitem> <listitem> -<url>*.example.org</url> wildcard formu 0.1.13 versiyonundan beri destekleniyor. +<literal>*.example.org</literal> wildcard formu 0.1.13 versiyonundan beri destekleniyor. </listitem> </list>