Mercurial > hg > nginx-site
changeset 490:9913f1d51c07
Replaced "nginx" domain names with example domains.
line wrap: on
line diff
--- a/xml/en/docs/http/configuring_https_servers.xml +++ b/xml/en/docs/http/configuring_https_servers.xml @@ -16,10 +16,10 @@ and private key files: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + 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; ... @@ -33,8 +33,8 @@ restricted access, however, it must be r The private key may alternately be stored in the same file as the certificate: <programlisting> - ssl_certificate www.nginx.com.cert; - ssl_certificate_key www.nginx.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> in which case the file access rights should also be restricted. @@ -101,12 +101,12 @@ http { server { listen 443; - server_name www.nginx.com; + server_name www.example.com; <b>keepalive_timeout 70</b>; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + 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; ... @@ -132,7 +132,7 @@ The server certificate must appear befor in the combined file: <programlisting> -$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt </programlisting> The resulting file should be used in the @@ -142,10 +142,10 @@ directive: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.chained.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -154,7 +154,7 @@ If the server certificate and the bundle order, nginx will fail to start and will display the error message: <programlisting> -SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch) </programlisting> @@ -231,9 +231,9 @@ and adding the <literal>ssl</literal> pa server { listen 80; listen 443 ssl; - server_name www.nginx.com; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -259,23 +259,23 @@ listening on a single IP address: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> With this configuration a browser receives the certificate of the default -server, i.e., <url>www.nginx.com</url> regardless of the requested server name. +server, i.e., <url>www.example.com</url> 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 @@ -289,17 +289,17 @@ is to assign a separate IP address for e <programlisting> server { listen 192.168.1.1:443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 192.168.1.2:443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -315,18 +315,18 @@ server { 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.nginx.com</url> -and <url>www.nginx.org</url>. +the SubjectAltName certificate field, for example, <url>www.example.com</url> +and <url>www.example.org</url>. However, the SubjectAltName field length is limited. </para> <para> Another way is to use a certificate with a wildcard name, for example, -<url>*.nginx.org</url>. This certificate matches -<url>www.nginx.org</url>, but does not match <url>nginx.org</url> -and <url>www.sub.nginx.org</url>. These two methods can also be combined. +<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. A certificate may contain exact and wildcard names in the SubjectAltName field, -for example, <url>nginx.org</url> and <url>*.nginx.org</url>. +for example, <url>example.org</url> and <url>*.example.org</url>. </para> <para> @@ -340,14 +340,14 @@ ssl_certificate_key common.key; server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; ... }
--- a/xml/en/docs/http/converting_rewrite_rules.xml +++ b/xml/en/docs/http/converting_rewrite_rules.xml @@ -13,8 +13,8 @@ People who during their shared hosting l usually translate the following rules: <programlisting> -RewriteCond %{HTTP_HOST} nginx.org -RewriteRule (.*) http://www.nginx.org$1 +RewriteCond %{HTTP_HOST} example.org +RewriteRule (.*) http://www.example.org$1 </programlisting> to something like this: @@ -22,9 +22,9 @@ to something like this: <programlisting> server { listen 80; - server_name www.nginx.org nginx.org; - if ($http_host = nginx.org) { - rewrite (.*) http://www.nginx.org$1; + server_name www.example.org example.org; + if ($http_host = example.org) { + rewrite (.*) http://www.example.org$1; } ... } @@ -33,18 +33,18 @@ server { <para> This is a wrong, cumbersome, and ineffective way. -The right way is to define a separate server for <url>nginx.org</url>: +The right way is to define a separate server for <url>example.org</url>: <programlisting> server { listen 80; - server_name nginx.org; - return 301 http://www.nginx.org$request_uri; + server_name example.org; + return 301 http://www.example.org$request_uri; } server { listen 80; - server_name www.nginx.org; + server_name www.example.org; ... } </programlisting> @@ -52,7 +52,7 @@ server { <note> On versions prior to 0.9.1, redirects can be made with: <programlisting> - rewrite ^ http://www.nginx.org$request_uri?; + rewrite ^ http://www.example.org$request_uri?; </programlisting> </note> @@ -66,35 +66,35 @@ On versions prior to 0.9.1, redirects ca <para> Another example. Instead of the “upside-down” logic “all that is not -<url>nginx.com</url> and is not <url>www.nginx.com</url>”: +<url>example.com</url> and is not <url>www.example.com</url>”: <programlisting> -RewriteCond %{HTTP_HOST} !nginx.com -RewriteCond %{HTTP_HOST} !www.nginx.com -RewriteRule (.*) http://www.nginx.com$1 +RewriteCond %{HTTP_HOST} !example.com +RewriteCond %{HTTP_HOST} !www.example.com +RewriteRule (.*) http://www.example.com$1 </programlisting> -one should simply define <url>nginx.com</url>, <url>www.nginx.com</url>, +one should simply define <url>example.com</url>, <url>www.example.com</url>, and “everything else”: <programlisting> server { listen 80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } server { listen 80 default_server; server_name _; - return 301 http://nginx.com$request_uri; + return 301 http://example.com$request_uri; } </programlisting> <note> On versions prior to 0.9.1, redirects can be made with: <programlisting> - rewrite ^ http://nginx.com$request_uri?; + rewrite ^ http://example.com$request_uri?; </programlisting> </note>
--- a/xml/en/docs/http/ngx_http_map_module.xml +++ b/xml/en/docs/http/ngx_http_map_module.xml @@ -27,9 +27,9 @@ map $http_host $name { example.com 1; *.example.com 1; - test.com 2; - *.test.com 2; - .site.com 3; + example.org 2; + *.example.org 2; + .example.net 3; wap.* 4; } </example>
--- a/xml/en/docs/http/ngx_http_referer_module.xml +++ b/xml/en/docs/http/ngx_http_referer_module.xml @@ -28,7 +28,7 @@ not send the <header>Referer</header> fi <para> <example> valid_referers none blocked server_names - *.example.com example.* www.example.info/galleries/ + *.example.com example.* www.example.org/galleries/ ~\.google\.; if ($invalid_referer) { @@ -104,7 +104,7 @@ the text starting after the “<literal>http://</literal>”. Example: <example> valid_referers none blocked server_names - *.example.com example.* www.example.info/galleries/ + *.example.com example.* www.example.org/galleries/ ~\.google\.; </example> </para>
--- a/xml/en/docs/http/request_processing.xml +++ b/xml/en/docs/http/request_processing.xml @@ -17,19 +17,19 @@ where all three virtual servers listen o <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -50,7 +50,7 @@ in the <link doc="ngx_http_core_module.x <programlisting> server { listen 80 <b>default_server</b>; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } </programlisting> @@ -107,19 +107,19 @@ where some virtual servers listen on dif <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -139,10 +139,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.nginx.com</url> received on +For example, a request for <url>www.example.com</url> 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.nginx.com</url> defined for this port. +since there is no <url>www.example.com</url> defined for this port. </para> <para> @@ -152,19 +152,19 @@ and different default servers may be def <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80 default_server; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80 default_server; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -183,7 +183,7 @@ for a typical, simple PHP site: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; root /data/www; location / {
--- a/xml/en/docs/http/server_names.xml +++ b/xml/en/docs/http/server_names.xml @@ -20,13 +20,13 @@ They may be defined using exact names, w <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name *.nginx.org; + server_name *.example.org; ... } @@ -38,7 +38,7 @@ server { server { listen 80; - server_name ~^(?<user>.+)\.nginx\.net$; + server_name ~^(?<user>.+)\.example\.net$; ... } </programlisting> @@ -52,7 +52,7 @@ exact names; </listitem> <listitem> -wildcard names starting with an asterisk: <url>*.nginx.org</url>; +wildcard names starting with an asterisk: <url>*.example.org</url>; </listitem> <listitem> @@ -75,20 +75,20 @@ The first match stops the search. <para> A wildcard name may contain an asterisk only on the name's start or end, -and only on a dot border. The names “<literal>www.*.nginx.org</literal>” -and “<literal>w*.nginx.org</literal>” are invalid. +and only on a dot border. The names “<literal>www.*.example.org</literal>” +and “<literal>w*.example.org</literal>” are invalid. However, these names can be specified using regular expressions, -for example, “<literal>~^www\..+\.nginx\.org$</literal>” and -“<literal>~^w.*\.nginx\.org$</literal>”. +for example, “<literal>~^www\..+\.example\.org$</literal>” and +“<literal>~^w.*\.example\.org$</literal>”. An asterisk can match several name parts. -The name “<literal>*.nginx.org</literal>” matches not only -<url>www.nginx.org</url> but <url>www.sub.nginx.org</url> as well. +The name “<literal>*.example.org</literal>” matches not only +<url>www.example.org</url> but <url>www.sub.example.org</url> as well. </para> <para> -A special wildcard in the form “<literal>.nginx.org</literal>” can be used -to match both the exact name “<literal>nginx.org</literal>” -and the wildcard name “<literal>*.nginx.org</literal>”. +A special wildcard in the form “<literal>.example.org</literal>” can be used +to match both the exact name “<literal>example.org</literal>” +and the wildcard name “<literal>*.example.org</literal>”. </para> </section> @@ -104,7 +104,7 @@ To use a regular expression, the server character: <programlisting> -server_name ~^www\d+\.nginx\.net$; +server_name ~^www\d+\.example\.net$; </programlisting> otherwise it will be treated as an exact name, or if the expression contains @@ -116,7 +116,7 @@ A regular expression containing the char and “}” should be quoted: <programlisting> -server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.nginx\.net$"; +server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.example\.net$"; </programlisting> otherwise nginx will fail to start and display the error message: @@ -196,7 +196,7 @@ in a server block which is not the defau <programlisting> server { listen 80; - server_name nginx.org www.nginx.org ""; + server_name example.org www.example.org ""; ... } </programlisting> @@ -221,8 +221,8 @@ and you can handle the request using the <programlisting> server { listen 80; - server_name nginx.org - www.nginx.org + server_name example.org + www.example.org "" <b>192.168.1.1</b> ; @@ -278,14 +278,14 @@ while the other will be the default for server { listen 80; listen 8080 default_server; - server_name nginx.net; + server_name example.net; ... } server { listen 80 default_server; listen 8080; - server_name nginx.org; + server_name example.org; ... } </programlisting> @@ -312,7 +312,7 @@ If the name is not found there, the wild ending with an asterisk is searched. Searching wildcard names hashes is slower than searching exact name hash because names are searched by domain parts. -Note that the special wildcard form “<literal>.nginx.org</literal>” +Note that the special wildcard form “<literal>.example.org</literal>” is stored in a wildcard names hash and not in an exact names hash. Regular expressions are tested sequentially and therefore are the slowest method and are non-scalable. @@ -321,13 +321,13 @@ and therefore are the slowest method and <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>nginx.org</url> and <url>www.nginx.org</url>, +are <url>example.org</url> and <url>www.example.org</url>, it is more efficient to define them explicitly: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org *.nginx.org; + server_name example.org www.example.org *.example.org; ... } </programlisting> @@ -337,7 +337,7 @@ than to use the simplified form: <programlisting> server { listen 80; - server_name .nginx.org; + server_name .example.org; ... } </programlisting> @@ -354,7 +354,7 @@ The default value of the may be equal to 32, or 64, or another value, depending on your CPU cache line size. If the default value is 32 and you define -“too.long.server.name.nginx.org” as a server name, +“too.long.server.name.example.org” as a server name, then nginx will fail to start and display the error message: <programlisting> @@ -433,15 +433,15 @@ Regular expression server names have bee </listitem> <listitem> -Wildcard form <url>nginx.*</url> has been supported since 0.6.0. +Wildcard form <url>example.*</url> has been supported since 0.6.0. </listitem> <listitem> -The special form <url>.nginx.org</url> has been supported since 0.3.18. +The special form <url>.example.org</url> has been supported since 0.3.18. </listitem> <listitem> -Wildcard form <url>*.nginx.org</url> has been supported since 0.1.13. +Wildcard form <url>*.example.org</url> has been supported since 0.1.13. </listitem> </list>
--- a/xml/he/docs/http/converting_rewrite_rules.xml +++ b/xml/he/docs/http/converting_rewrite_rules.xml @@ -14,8 +14,8 @@ הכללים הבאים: <programlisting> -RewriteCond %{HTTP_HOST} nginx.org -RewriteRule (.*) http://www.nginx.org$1 +RewriteCond %{HTTP_HOST} example.org +RewriteRule (.*) http://www.example.org$1 </programlisting> למשהו כזה: @@ -23,9 +23,9 @@ RewriteRule (.*) http://www.ng <programlisting> server { listen 80; - server_name www.nginx.org nginx.org; - if ($http_host = nginx.org) { - rewrite (.*) http://www.nginx.org$1; + server_name www.example.org example.org; + if ($http_host = example.org) { + rewrite (.*) http://www.example.org$1; } ... } @@ -34,18 +34,18 @@ server { <para> צורה זו היא שגוייה, מסובכת, ולא יעילה. -הדרך הנכונה היא להגדיר שרת נפרד עבור <url>nginx.org</url>: +הדרך הנכונה היא להגדיר שרת נפרד עבור <url>example.org</url>: <programlisting> server { listen 80; - server_name nginx.org; - rewrite ^ http://www.nginx.org$request_uri?; + server_name example.org; + rewrite ^ http://www.example.org$request_uri?; } server { listen 80; - server_name www.nginx.org; + server_name www.example.org; ... } </programlisting> @@ -58,28 +58,28 @@ server { <para> דוגמה נוספת, במקום הגיון הפוך: כל מה שהוא לא -<url>nginx.com</url> וגם לא <url>www.nginx.com</url>: +<url>example.com</url> וגם לא <url>www.example.com</url>: <programlisting> -RewriteCond %{HTTP_HOST} !nginx.com -RewriteCond %{HTTP_HOST} !www.nginx.com -RewriteRule (.*) http://www.nginx.com$1 +RewriteCond %{HTTP_HOST} !example.com +RewriteCond %{HTTP_HOST} !www.example.com +RewriteRule (.*) http://www.example.com$1 </programlisting> -עלייך רק להגדיר את <url>nginx.com</url>, <url>www.nginx.com</url>, +עלייך רק להגדיר את <url>example.com</url>, <url>www.example.com</url>, וכל דבר אחר: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80 default_server; server_name _; - rewrite ^ http://nginx.org$request_uri?; + rewrite ^ http://example.org$request_uri?; } </programlisting> </para>
--- a/xml/he/docs/http/server_names.xml +++ b/xml/he/docs/http/server_names.xml @@ -17,13 +17,13 @@ <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name *.nginx.org; + server_name *.example.org; ... } @@ -35,7 +35,7 @@ server { server { listen 80; - server_name ~^(?<user>.+)\.nginx\.net$; + server_name ~^(?<user>.+)\.example\.net$; ... } </programlisting> @@ -49,7 +49,7 @@ server { </listitem> <listitem> -שמות Wildcard המתחילים בכוכבית: <url>*.nginx.org</url>; +שמות Wildcard המתחילים בכוכבית: <url>*.example.org</url>; </listitem> <listitem> @@ -72,20 +72,20 @@ server { <para> שם wildcard יכול להכיל כוכבית רק בתחילת או בסוף השם, וחייב להיות בגבול של נקודה. -השמות <literal>www.*.nginx.org</literal> -ו <literal>w*.nginx.org</literal> הם שגויים. +השמות <literal>www.*.example.org</literal> +ו <literal>w*.example.org</literal> הם שגויים. למרות זאת, ניתן לציין שמות כאלה באמצעות ביטויים רגולריים, -לדוגמא, <literal>~^www\..+\.nginx\.org$</literal> ו -<literal>~^w.*\.nginx\.org$</literal>. +לדוגמא, <literal>~^www\..+\.example\.org$</literal> ו +<literal>~^w.*\.example\.org$</literal>. סימן הכוכבית יכול להחליף מספר חלקי שם. -השם <literal>*.nginx.org</literal> מתאים לא רק ל -<url>www.nginx.org</url> אלא גם ל <url>www.sub.nginx.org</url>. +השם <literal>*.example.org</literal> מתאים לא רק ל +<url>www.example.org</url> אלא גם ל <url>www.sub.example.org</url>. </para> <para> -ניתן להשתמש ב wildcard מיוחד בצורה של <literal>.nginx.org</literal> -כדי להתאים גם לשם המדוייק <literal>nginx.org</literal> -וגם לשם ה wildcard הבא: <literal>*.nginx.org</literal>. +ניתן להשתמש ב wildcard מיוחד בצורה של <literal>.example.org</literal> +כדי להתאים גם לשם המדוייק <literal>example.org</literal> +וגם לשם ה wildcard הבא: <literal>*.example.org</literal>. </para> </section> @@ -100,7 +100,7 @@ server { כדי להשתמש בביטוי רגולרי, על שם השרת להתחיל עם סימן הטילדה (~), כך: <programlisting> -server_name ~^www\d+\.nginx\.net$; +server_name ~^www\d+\.example\.net$; </programlisting> אחרת nginx יתייחס אליו כשם מדוייק, או אם הביטוי מכיל כוכבית, כשם wildcard (וסביר @@ -113,7 +113,7 @@ server_name ~^www\d+\.nginx\.net$; ו “}” צריך להיות במרכאות: <programlisting> -server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.nginx\.net$"; +server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.example\.net$"; </programlisting> אחרת nginx יכשל בעלייה, ויציג את הודעת השגיאה הבאה: @@ -199,7 +199,7 @@ server { <programlisting> server { listen 80; - server_name nginx.org www.nginx.org ""; + server_name example.org www.example.org ""; ... } </programlisting> @@ -213,8 +213,8 @@ server { <programlisting> server { listen 80; - server_name nginx.org - www.nginx.org + server_name example.org + www.example.org "" <b>192.168.1.1</b> ; @@ -260,14 +260,14 @@ nginx בגירסאות עד 0.6.25 תמך בשם המיוחד “*” server { listen 80; listen 8080 default_server; - server_name nginx.net; + server_name example.net; ... } server { listen 80 default_server; listen 8080; - server_name nginx.org; + server_name example.org; ... } </programlisting> @@ -294,7 +294,7 @@ server { אם הוא לא נמצא גם שם, מתחיל חיפוש בגיבוב השמות המסתיימים בכוכבית. חיפוש בגיבובי שמות wildcard הוא איטי יותר מחיפוש שם בגיבוב השמות המדוייקים כיוון ששמות עוברים חיפוש על פי חלקי שם המתחם. -שימו לב שצורת ה wildcard המיוחדת <literal>.nginx.org</literal> +שימו לב שצורת ה wildcard המיוחדת <literal>.example.org</literal> שמורה גם היא בגיבוב שמות ה wildcard ולא בגיבוב השמות המדוייקים. ביטויים רגולריים נבדקים באופן סדרתי, ועל כן הם השיטה האיטית ביותר ואינם סקאלאביליים. @@ -302,13 +302,13 @@ server { <para> בהתחשב בנסיבות אלה, הכי טוב להשתמש בשמות מדוייקים בכל מקום שהדבר אפשרי. -לדוגמה, אם השמות הנפוצים ביותר לשרת הם <url>nginx.org</url> ו <url>www.nginx.org</url>, +לדוגמה, אם השמות הנפוצים ביותר לשרת הם <url>example.org</url> ו <url>www.example.org</url>, יותר יעיל להגדיר אותם באופן מפורש: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org *.nginx.org; + server_name example.org www.example.org *.example.org; ... } </programlisting> @@ -318,7 +318,7 @@ server { <programlisting> server { listen 80; - server_name .nginx.org; + server_name .example.org; ... } </programlisting> @@ -331,7 +331,7 @@ server { ערך ברירת המחדל של <literal>server_names_hash_bucket_size</literal> יכול להיות שווה ל 32, ל 64, או לערך אחר, בהתאם לגודל קו המטמון של המעבד שלכם. אם ברירת המחדל היא 32 ותגדירו -“too.long.server.name.nginx.org” בתור שם שרת, +“too.long.server.name.example.org” בתור שם שרת, אזי nginx ייכשל בעלייה ויציג את הודעת השגיאה הבאה: <programlisting> @@ -400,15 +400,15 @@ nginx חייב לבצע את הביטוי כדי לקבל את מה שנלכד בהן. </listitem> <listitem> -צורות Wildcard מסוג <url>nginx.*</url> נתמכו החל מגירסה 0.6.0. +צורות Wildcard מסוג <url>example.*</url> נתמכו החל מגירסה 0.6.0. </listitem> <listitem> -הצורה המיוחדת <url>.nginx.org</url> נתמכה החל מגירסה 0.3.18. +הצורה המיוחדת <url>.example.org</url> נתמכה החל מגירסה 0.3.18. </listitem> <listitem> -הצורה <url>*.nginx.org</url> נתמכה החל מגירסה 0.1.13. +הצורה <url>*.example.org</url> נתמכה החל מגירסה 0.1.13. </listitem> </list>
--- a/xml/ja/docs/http/configuring_https_servers.xml +++ b/xml/ja/docs/http/configuring_https_servers.xml @@ -14,10 +14,10 @@ HTTPS サーバを設定するには server ブロックで SSL プロトコルを有効にして、サーバ証明書ファイルと秘密鍵ファイルの場所を指定する必要があります: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ... @@ -27,8 +27,8 @@ server { サーバ証明書とはドメインの所有者情報や、送信情報の暗号化に必要な公開鍵を含む電子証明書です。そのサーバに接続するすべてのクライアントに送られます。秘密鍵はサーバ証明書に含まれる公開鍵で暗号化された情報を復号するために必要な鍵で、秘匿する必要が有ります。アクセスを制限したファイルに保存するようにしてください。ただし、nginx のマスタープロセスからは読めるようにする必要があります。もうひとつの方法として、秘密鍵は証明書と同じファイルに保存することもできます: <programlisting> - ssl_certificate www.nginx.com.cert; - ssl_certificate_key www.nginx.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> この場合もファイルのアクセス権は制限するようにします。証明書と秘密鍵がひとつのファイルに保存されていても、証明書だけがクライアントに送られます。 @@ -56,12 +56,12 @@ http { server { listen 443; - server_name www.nginx.com; + server_name www.example.com; <b>keepalive_timeout 70</b>; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ... @@ -77,7 +77,7 @@ http { ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります: <programlisting> -$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt </programlisting> この結合されたファイルを <literal>ssl_certificate</literal> ディレクティブで使われるようにします: @@ -85,10 +85,10 @@ http { <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.chained.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -96,7 +96,7 @@ server { サーバ証明書とバンドルされたものが間違った順序で連結されていた場合、nginx は起動に失敗して次のエラーメッセージを表示します: <programlisting> -SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch) </programlisting> @@ -152,9 +152,9 @@ Certificate chain server { listen 80; listen 443 ssl; - server_name www.nginx.com; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -178,22 +178,22 @@ listen 443 default ssl; <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> -この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは <url>www.nginx.com</url> の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 +この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは <url>www.example.com</url> の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。 </para> <para> @@ -202,17 +202,17 @@ server { <programlisting> server { listen 192.168.1.1:443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 192.168.1.2:443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -225,11 +225,11 @@ server { name="複数サーバ名をもつ SSL 証明書"> <para> -単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<url>www.nginx.com</url> と <url>www.nginx.org</url>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 +単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、<url>www.example.com</url> と <url>www.example.org</url>）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。 </para> <para> -もうひとつの方法は、例えば <url>*.nginx.org</url> のようにワイルドカード名を持った証明書を使用する方法です。この証明書は <url>www.nginx.org</url> にマッチしますが <url>nginx.org</url> や <url>www.sub.nginx.org</url> にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば <url>nginx.org</url> と <url>*.nginx.org</url> のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。 +もうひとつの方法は、例えば <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 フィールドに完全一致名とワイルドカード名を含ませることができます。 </para> <para> @@ -241,14 +241,14 @@ ssl_certificate_key common.key; server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; ... }
--- a/xml/ja/docs/http/converting_rewrite_rules.xml +++ b/xml/ja/docs/http/converting_rewrite_rules.xml @@ -10,8 +10,8 @@ 共有のホスティングで Apache の .htaccess ファイル<i>のみ</i>で<i>すべて</i>を設定してきたのなら、次のようにルールをコンバートします: <programlisting> -RewriteCond %{HTTP_HOST} nginx.org -RewriteRule (.*) http://www.nginx.org$1 +RewriteCond %{HTTP_HOST} example.org +RewriteRule (.*) http://www.example.org$1 </programlisting> 上記は下記のようになります: @@ -19,9 +19,9 @@ RewriteRule (.*) http://www.ng <programlisting> server { listen 80; - server_name www.nginx.org nginx.org; - if ($http_host = nginx.org) { - rewrite (.*) http://www.nginx.org$1; + server_name www.example.org example.org; + if ($http_host = example.org) { + rewrite (.*) http://www.example.org$1; } ... } @@ -29,18 +29,18 @@ server { </para> <para> -これは間違っていて面倒で非効率的な方法です。正しい方法は <url>nginx.org</url> 用に別のサーバを定義します: +これは間違っていて面倒で非効率的な方法です。正しい方法は <url>example.org</url> 用に別のサーバを定義します: <programlisting> server { listen 80; - server_name nginx.org; - rewrite ^ http://www.nginx.org$request_uri?; + server_name example.org; + rewrite ^ http://www.example.org$request_uri?; } server { listen 80; - server_name www.nginx.org; + server_name www.example.org; ... } </programlisting> @@ -52,28 +52,28 @@ server { <section> <para> -別の例として、<url>nginx.com</url> 以外と <url>www.nginx.com</url> 以外のすべて、という後方ロジックの代わりの例です: +別の例として、<url>example.com</url> 以外と <url>www.example.com</url> 以外のすべて、という後方ロジックの代わりの例です: <programlisting> -RewriteCond %{HTTP_HOST} !nginx.com -RewriteCond %{HTTP_HOST} !www.nginx.com -RewriteRule (.*) http://www.nginx.com$1 +RewriteCond %{HTTP_HOST} !example.com +RewriteCond %{HTTP_HOST} !www.example.com +RewriteRule (.*) http://www.example.com$1 </programlisting> -この場合、単に <url>nginx.com</url>、<url>www.nginx.com</url>、そしてそれ以外を定義します: +この場合、単に <url>example.com</url>、<url>www.example.com</url>、そしてそれ以外を定義します: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80 default_server; server_name _; - rewrite ^ http://nginx.org$request_uri?; + rewrite ^ http://example.org$request_uri?; } </programlisting> </para>
--- a/xml/ja/docs/http/request_processing.xml +++ b/xml/ja/docs/http/request_processing.xml @@ -14,19 +14,19 @@ nginx はまず最初にどの<i>サーバ</i>がそのリクエストを処理すべきなのかを決定します。手はじめに、３つすべての仮想サーバが port *:80 で待ち受けている単純な設定から見てみましょう: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -38,7 +38,7 @@ server { <programlisting> server { listen 80 <b>default_server</b>; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } </programlisting> @@ -82,26 +82,26 @@ server { <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> この設定では、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.nginx.com</url> へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは <url>www.nginx.com</url> は定義されていないからです。 +もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、192.168.1.1:80 ポートで受信された <url>www.example.com</url> へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは <url>www.example.com</url> は定義されていないからです。 </para> <para> @@ -110,19 +110,19 @@ server { <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80 default_server; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80 default_server; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -140,7 +140,7 @@ server { <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; root /data/www; location / {
--- a/xml/ja/docs/http/server_names.xml +++ b/xml/ja/docs/http/server_names.xml @@ -14,13 +14,13 @@ <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name *.nginx.org; + server_name *.example.org; ... } @@ -32,7 +32,7 @@ server { server { listen 80; - server_name ~^(?<user>.+)\.nginx\.net$; + server_name ~^(?<user>.+)\.example\.net$; ... } </programlisting> @@ -46,7 +46,7 @@ server { </listitem> <listitem> -アスタリスクで始まるワイルドカード名: <url>*.nginx.org</url> +アスタリスクで始まるワイルドカード名: <url>*.example.org</url> </listitem> <listitem> @@ -68,11 +68,11 @@ server { 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.*.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> にもマッチします。 </para> <para> -特別なワイルドカードの形式 <literal>.nginx.org</literal> は、完全一致名 <literal>nginx.org</literal> とワイルドカード名 <literal>*.nginx.org</literal> の両方にマッチさせるように利用できます。 +特別なワイルドカードの形式 <literal>.example.org</literal> は、完全一致名 <literal>example.org</literal> とワイルドカード名 <literal>*.example.org</literal> の両方にマッチさせるように利用できます。 </para> </section> @@ -85,13 +85,13 @@ server { nginx で使用される正規表現は Perl プログラミング言語（PCRE）で使用されているものと互換性があります。正規表現を使用するには、サーバ名を必ずチルダで始めます: <programlisting> -server_name ~^www\d+\.nginx\.net$; +server_name ~^www\d+\.example\.net$; </programlisting> チルダで始まっていないと完全一致名として、またはその正規表現にアスタリスクが含まれている場合はワイルドカード名として（そしてたいていの場合は無効なものとして）扱われてしまいます。“^” と “$” アンカーをセットし忘れないようにしてください。これらは構文的には必須ではありませんが論理的に必須です。また、ドメイン名のドットはバックスラッシュで必ずエスケープしてください。“{” と “}” 文字を含む正規表現は必ずダブルクォーテーションで囲ってください: <programlisting> -server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.nginx\.net$"; +server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.example\.net$"; </programlisting> さもないと、nginx は起動に失敗し次のエラーメッセージを表示します: @@ -167,7 +167,7 @@ server { <programlisting> server { listen 80; - server_name nginx.org www.nginx.org ""; + server_name example.org www.example.org ""; ... } </programlisting> @@ -188,8 +188,8 @@ nginx のバージョン 0.8.48 までは、このような場合はサーバ名としてホスト名を使用していました。 <programlisting> server { listen 80; - server_name nginx.org - www.nginx.org + server_name example.org + www.example.org "" <b>192.168.1.1</b> ; @@ -220,14 +220,14 @@ nginx バージョン 0.6.25 までは特別なサーバ名 “*” をサポートしていて、これは誤ってすべてのサーバ名と一致するもの（キャッチオール名）として解釈されていました。この特別なサーバ名 “*”はキャッチオールまたはワイルドカードとして機能したことはありませんでした。代わりに、今は <literal>server_name_in_redirect</literal> ディレクティブによって提供されている機能の役を果たしていました。特別なサーバ名 “*” は今後廃止予定ですので、<literal>server_name_in_redirect</literal> ディレクティブを使うようにしてください。キャッチオール名を指定したり <literal>server_name</literal> ディレクティブを使用した<i>デフォルト</i>サーバを指定したりする方法はないことに注意してください。これは <literal>listen</literal> ディレクティブのプロパティであり、<literal>server_name</literal> ディレクティブのプロパティではありません。“<link doc="request_processing.xml" />” も参照してください。 server { listen 80; listen 8080 default_server; - server_name nginx.net; + server_name example.net; ... } server { listen 80 default_server; listen 8080; - server_name nginx.org; + server_name example.org; ... } </programlisting> @@ -241,16 +241,16 @@ server { name="最適化"> <para> -完全一致名とワイルドカード名はハッシュで保存されます。このハッシュは待ち受けポートに結び付けられ、各待ち受けポートは、完全一致名のハッシュ、アスタリスクで始まるワイルドカード名のハッシュ、アスタリスクで終わるワイルドカード名のハッシュの３つまでのハッシュを持つことができます。ハッシュのサイズは構成フェーズで最適化されるので、CPU キャッシュのミスは最低でもサーバ名を見つけることができます。最初に完全一致名のハッシュが検索されます。完全一致名のハッシュを使って見つからなければ、次にアスタリスクで始まるワイルドカード名のハッシュが検索されます。さらにまだ見つからなければ、アスタリスクで終わるワイルドカード名のハッシュが検索されます。ワイルドカード名のハッシュの検索は完全一致名のハッシュの検索よりも遅くなります。これはサーバ名の検索がドメイン部分によって検索されるからです。特別なワイルドカード形式の <literal>.nginx.org</literal> は完全一致名のハッシュではなくワイルドカード名のハッシュで保存されます。正規表現は順番に考査されるので、これがもっとも遅い方式ですし、非スケーラブルでもあります。 +完全一致名とワイルドカード名はハッシュで保存されます。このハッシュは待ち受けポートに結び付けられ、各待ち受けポートは、完全一致名のハッシュ、アスタリスクで始まるワイルドカード名のハッシュ、アスタリスクで終わるワイルドカード名のハッシュの３つまでのハッシュを持つことができます。ハッシュのサイズは構成フェーズで最適化されるので、CPU キャッシュのミスは最低でもサーバ名を見つけることができます。最初に完全一致名のハッシュが検索されます。完全一致名のハッシュを使って見つからなければ、次にアスタリスクで始まるワイルドカード名のハッシュが検索されます。さらにまだ見つからなければ、アスタリスクで終わるワイルドカード名のハッシュが検索されます。ワイルドカード名のハッシュの検索は完全一致名のハッシュの検索よりも遅くなります。これはサーバ名の検索がドメイン部分によって検索されるからです。特別なワイルドカード形式の <literal>.example.org</literal> は完全一致名のハッシュではなくワイルドカード名のハッシュで保存されます。正規表現は順番に考査されるので、これがもっとも遅い方式ですし、非スケーラブルでもあります。 </para> <para> -これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が <url>nginx.org</url> と <url>www.nginx.org</url> だとすると、これらを明示的に定義するとより効率的です: +これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が <url>example.org</url> と <url>www.example.org</url> だとすると、これらを明示的に定義するとより効率的です: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org *.nginx.org; + server_name example.org www.example.org *.example.org; ... } </programlisting> @@ -260,14 +260,14 @@ server { <programlisting> server { listen 80; - server_name .nginx.org; + server_name .example.org; ... } </programlisting> </para> <para> -たくさんの数のサーバ名を定義したり非常に長いサーバ名を定義したりする場合は、http レベルの <literal>server_names_hash_max_size</literal> と <literal>server_names_hash_bucket_size</literal> ディレクティブを調整する必要があるかもしれません。<literal>server_names_hash_bucket_size</literal> のデフォルト値は 32、もしくは 64、あるいはお使いの CPU キャッシュラインのサイズによってはその他の値になっているかもしれません。もしデフォルト値が 32 でサーバ名として “too.long.server.name.nginx.org” のような非常に長いサーバ名を定義している場合、nginx は起動に失敗し、次のエラーメッセージを表示させます: +たくさんの数のサーバ名を定義したり非常に長いサーバ名を定義したりする場合は、http レベルの <literal>server_names_hash_max_size</literal> と <literal>server_names_hash_bucket_size</literal> ディレクティブを調整する必要があるかもしれません。<literal>server_names_hash_bucket_size</literal> のデフォルト値は 32、もしくは 64、あるいはお使いの CPU キャッシュラインのサイズによってはその他の値になっているかもしれません。もしデフォルト値が 32 でサーバ名として “too.long.server.name.example.org” のような非常に長いサーバ名を定義している場合、nginx は起動に失敗し、次のエラーメッセージを表示させます: <programlisting> could not build the server_names_hash, @@ -331,15 +331,15 @@ 0.8.48 以降、デフォルトのサーバ名の値は空の名前 “” です。 </listitem> <listitem> -ワイルドカードの形式 <url>nginx.*</url> のサポートは 0.6.0 からです。 +ワイルドカードの形式 <url>example.*</url> のサポートは 0.6.0 からです。 </listitem> <listitem> -特別な形式 <url>.nginx.org</url> のサポートは 0.3.18 からです。 +特別な形式 <url>.example.org</url> のサポートは 0.3.18 からです。 </listitem> <listitem> -ワイルドカードの形式 <url>*.nginx.org</url> のサポートは 0.1.13 からです。 +ワイルドカードの形式 <url>*.example.org</url> のサポートは 0.1.13 からです。 </listitem> </list>
--- a/xml/ru/docs/http/ngx_http_map_module.xml +++ b/xml/ru/docs/http/ngx_http_map_module.xml @@ -27,9 +27,9 @@ map $http_host $name { example.com 1; *.example.com 1; - test.com 2; - *.test.com 2; - .site.com 3; + example.org 2; + *.example.org 2; + .example.net 3; wap.* 4; } </example>
--- a/xml/ru/docs/http/ngx_http_referer_module.xml +++ b/xml/ru/docs/http/ngx_http_referer_module.xml @@ -29,7 +29,7 @@ <para> <example> valid_referers none blocked server_names - *.example.com example.* www.example.info/galleries/ + *.example.com example.* www.example.org/galleries/ ~\.google\.; if ($invalid_referer) { @@ -104,7 +104,7 @@ if ($invalid_referer) { Пример: <example> valid_referers none blocked server_names - *.example.com example.* www.example.info/galleries/ + *.example.com example.* www.example.org/galleries/ ~\.google\.; </example> </para>
--- a/xml/tr/docs/http/configuring_https_servers.xml +++ b/xml/tr/docs/http/configuring_https_servers.xml @@ -14,10 +14,10 @@ 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: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ... @@ -27,8 +27,8 @@ server { 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: <programlisting> - ssl_certificate www.nginx.com.cert; - ssl_certificate_key www.nginx.com.cert; + ssl_certificate www.example.com.cert; + ssl_certificate_key www.example.com.cert; </programlisting> Bu durumda dosya erişimi kısıtlanmalıdır. Aynı dosyada yer alsalar da istemciye sadece sertifika gönderilir. @@ -57,12 +57,12 @@ http { server { listen 443; - server_name www.nginx.com; + server_name www.example.com; <b>keepalive_timeout 70</b>; ssl on; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH:!MD5; ... @@ -78,7 +78,7 @@ http { 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: <programlisting> -$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt +$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt </programlisting> Oluşan dosya <literal>ssl_certificate</literal> yönergesi içinde kullanılmalıdır: @@ -86,10 +86,10 @@ Oluşan dosya <literal>ssl_certificate</literal> yönergesi içinde kullanılmalıdır: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.chained.crt; - ssl_certificate_key www.nginx.com.key; + ssl_certificate www.example.com.chained.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -97,7 +97,7 @@ server { Eğer bu art arda diziliş yanlış yapılmış olursa, nginx başlamayacak ve aşağıdakine benzer bir hata mesajını verecektir: <programlisting> -SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed +SSL_CTX_use_PrivateKey_file(" ... /www.example.com.key") failed (SSL: error:0B080074:x509 certificate routines: X509_check_private_key:key values mismatch) </programlisting> @@ -153,9 +153,9 @@ 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, <literal>ssl on</literal> yönergesini silerek ve *:443 portu için <literal>ssl</literal> parametresi ekleyerek, HTTP ve HTTPS taleplerini tutan yalnızca bir sunucu yapılandırabilirsiniz: server { listen 80; listen 443 ssl; - server_name www.nginx.com; - ssl_certificate www.nginx.com.crt; - ssl_certificate_key www.nginx.com.key; + server_name www.example.com; + ssl_certificate www.example.com.crt; + ssl_certificate_key www.example.com.key; ... } </programlisting> @@ -179,22 +179,22 @@ Bir IP adresini dinleyen iki veya daha fazla HTTPS sunucusunu yapılandırdığınız zaman genel bir problem ortaya çıkar: <programlisting> server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> -Bu yapılandırmada, bir tarayıcı talep edilen sunucuya bakmadan, varsayılan sunucunun sertifikasını alır, örneğin: <url>www.nginx.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: <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. </para> <para> @@ -203,17 +203,17 @@ Bu problemi çözmenin en eski ve sağlam methodu HTTPS sunucularının her birine ayrı IP adresleri atamaktır: <programlisting> server { listen 192.168.1.1:443; - server_name www.nginx.com; + server_name www.example.com; ssl on; - ssl_certificate www.nginx.com.crt; + ssl_certificate www.example.com.crt; ... } server { listen 192.168.1.2:443; - server_name www.nginx.org; + server_name www.example.org; ssl on; - ssl_certificate www.nginx.org.crt; + ssl_certificate www.example.org.crt; ... } </programlisting> @@ -226,11 +226,11 @@ server { 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.nginx.com</url> ve <url>www.nginx.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: <url>www.example.com</url> ve <url>www.example.org</url>. 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>*.nginx.org</url>. Bu sertifika <url>www.nginx.org</url> ile eşleşir ancak <url>nginx.org</url> ve <url>www.sub.nginx.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>nginx.org</url> ve <url>*.nginx.org</url>. +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>. </para> <para> @@ -242,14 +242,14 @@ ssl_certificate_key common.key; server { listen 443; - server_name www.nginx.com; + server_name www.example.com; ssl on; ... } server { listen 443; - server_name www.nginx.org; + server_name www.example.org; ssl on; ... }
--- a/xml/tr/docs/http/converting_rewrite_rules.xml +++ b/xml/tr/docs/http/converting_rewrite_rules.xml @@ -10,8 +10,8 @@ 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: <programlisting> -RewriteCond %{HTTP_HOST} nginx.org -RewriteRule (.*) http://www.nginx.org$1 +RewriteCond %{HTTP_HOST} example.org +RewriteRule (.*) http://www.example.org$1 </programlisting> kuralı, nginx içerisinde şu şekilde yapılıyor: @@ -19,9 +19,9 @@ kuralı, nginx içerisinde şu şekilde yapılıyor: <programlisting> server { listen 80; - server_name www.nginx.org nginx.org; - if ($http_host = nginx.org) { - rewrite (.*) http://www.nginx.org$1; + server_name www.example.org example.org; + if ($http_host = example.org) { + rewrite (.*) http://www.example.org$1; } ... } @@ -34,13 +34,13 @@ Bu yanlış, kullanışsız ve etkisiz bir yoldur. Doğru olan ayrı bir sunucu tanımlaması yapmaktır: <programlisting> server { listen 80; - server_name nginx.org; - rewrite ^ http://www.nginx.org$request_uri?; + server_name example.org; + rewrite ^ http://www.example.org$request_uri?; } server { listen 80; - server_name www.nginx.org; + server_name www.example.org; ... } </programlisting> @@ -52,27 +52,27 @@ server { <section> <para> -Diğer bir örnek ile aşağıdaki geri kalmış mantık yerine (<url>nginx.com</url> olmayan her şey ve <url>www.nginx.com</url> olmayan her şey): +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): <programlisting> -RewriteCond %{HTTP_HOST} !nginx.com -RewriteCond %{HTTP_HOST} !www.nginx.com -RewriteRule (.*) http://www.nginx.com$1 +RewriteCond %{HTTP_HOST} !example.com +RewriteCond %{HTTP_HOST} !www.example.com +RewriteRule (.*) http://www.example.com$1 </programlisting> -sadece <url>nginx.com</url>, <url>www.nginx.com</url> ve diğer her şeyi ayrı ayrı tanımlamalısınız: +sadece <url>example.com</url>, <url>www.example.com</url> ve diğer her şeyi ayrı ayrı tanımlamalısınız: <programlisting> server { listen 80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } server { listen 80 default_server; server_name _; - rewrite ^ http://nginx.com$request_uri?; + rewrite ^ http://example.com$request_uri?; } </programlisting> </para>
--- a/xml/tr/docs/http/request_processing.xml +++ b/xml/tr/docs/http/request_processing.xml @@ -15,19 +15,19 @@ 80 portunu dinleyen 3 sunucunun olduğu bir yapılandırma ile örnek verelim: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -42,7 +42,7 @@ Eğer ilk server ifadesinin varsayılan olmasını istemiyorsanız, <literal>listen</literal> yönergesinde <literal>default_server</literal> parametresini kullanabilirsiniz: <programlisting> server { listen 80 <b>default_server</b>; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } </programlisting> @@ -87,26 +87,26 @@ Farklı adreslerde bulunan sanal sunucuların yer aldığı biraz daha karışık bir yapılandırmayı inceleyelim: <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> 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.nginx.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.nginx.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, <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. </para> <para> @@ -115,19 +115,19 @@ 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: <programlisting> server { listen 192.168.1.1:80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 192.168.1.1:80 default_server; - server_name nginx.net www.nginx.net; + server_name example.net www.example.net; ... } server { listen 192.168.1.2:80 default_server; - server_name nginx.com www.nginx.com; + server_name example.com www.example.com; ... } </programlisting> @@ -145,7 +145,7 @@ nginx’in basit bir PHP sitesi için gelen talebi işlemek için nasıl bir <i>lokasyon</i> seçtiğini inceleyelim: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; root /data/www; location / {
--- a/xml/tr/docs/http/server_names.xml +++ b/xml/tr/docs/http/server_names.xml @@ -14,13 +14,13 @@ Sunucu adları <literal>server_name</literal> 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 “<link doc="request_processing.xml" />”. Gerçek, wildcard veya düzenli ifadeler şeklinde tanımlanabilirler. <programlisting> server { listen 80; - server_name nginx.org www.nginx.org; + server_name example.org www.example.org; ... } server { listen 80; - server_name *.nginx.org; + server_name *.example.org; ... } @@ -32,7 +32,7 @@ server { server { listen 80; - server_name ~^(?<user>.+)\.nginx\.net$; + server_name ~^(?<user>.+)\.example\.net$; ... } </programlisting> @@ -46,7 +46,7 @@ gerçek adlar; </listitem> <listitem> -* ile başlayan wildcard adlar: <url>*.nginx.org</url>; +* ile başlayan wildcard adlar: <url>*.example.org</url>; </listitem> <listitem> @@ -68,11 +68,11 @@ ve düzenli ifadeler (regular expressions). 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.*.nginx.org</literal> ve <literal>w*.nginx.org</literal> adları geçersizdir. Ancak bu adlar düzenli ifadeler ile geçerli hale getirilebilir, örneğin, <literal>~^www\..+\.nginx\.org$</literal> ve <literal>~^w.*\.nginx\.org$</literal>. Buradaki * bir çok eşleşmeyi tanımlayabilir. <literal>*.nginx.org</literal> ifadesi <url>www.nginx.org</url> ve <url>www.sub.nginx.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 <url>www.example.org</url> ve <url>www.sub.example.org</url> adlarına karşılık gelebilir. </para> <para> -<literal>.nginx.org</literal> şeklindeki bir wildcard <literal>nginx.org</literal> gerçek adı ile <literal>*.nginx.org</literal> wildcard adına karşılık gelir. +<literal>.example.org</literal> şeklindeki bir wildcard <literal>example.org</literal> gerçek adı ile <literal>*.example.org</literal> wildcard adına karşılık gelir. </para> </section> @@ -86,7 +86,7 @@ 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: <programlisting> -server_name ~^www\d+\.nginx\.net$; +server_name ~^www\d+\.example\.net$; </programlisting> 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). @@ -96,7 +96,7 @@ 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: <programlisting> -server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.nginx\.net$"; +server_name "~^(?<name>\w\d<b>{</b>1,3<b>}</b>+)\.example\.net$"; </programlisting> diğer türlü, nginx şu şekilde bir hata verecektir: @@ -177,7 +177,7 @@ 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: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org ""; + server_name example.org www.example.org ""; ... } </programlisting> @@ -189,8 +189,8 @@ 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: <programlisting> server { listen 80; - server_name nginx.org - www.nginx.org + server_name example.org + www.example.org "" <b>192.168.1.1</b> ; @@ -227,14 +227,14 @@ Ayrıca bakınız “<link doc="request_processing.xml" />”. server { listen 80; listen 8080 default_server; - server_name nginx.net; + server_name example.net; ... } server { listen 80 default_server; listen 8080; - server_name nginx.org; + server_name example.org; ... } </programlisting> @@ -248,16 +248,16 @@ server { name="Optimizasyon"> <para> -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 <literal>.nginx.org</literal> 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. +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 <literal>.example.org</literal> 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. </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>nginx.org</url> ve <url>www.nginx.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ı <url>example.org</url> ve <url>www.example.org</url> ise bunları açıkca belirtmek daha etkili olacaktır: <programlisting> server { listen 80; - server_name nginx.org www.nginx.org *.nginx.org; + server_name example.org www.example.org *.example.org; ... } </programlisting> @@ -267,7 +267,7 @@ bu kullanım aşağıdaki basit kullanımdan daha etkili olacaktır: <programlisting> server { listen 80; - server_name .nginx.org; + server_name .example.org; ... } </programlisting> @@ -275,7 +275,7 @@ server { <para> Eğer çok miktarda veya olağandışı şekilde uzun sunucu adları tanımladıysanız, <i>http</i> düzeyinde <literal>server_names_hash_max_size</literal> -ve <literal>server_names_hash_bucket_size</literal> yönergelerini tekrar ayarlamalısınız. <literal>server_names_hash_bucket_size</literal> 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.nginx.org” ifadesini sunucu adı olarak belirlerseniz nginx, başlamayacak ve aşağıdaki hatayı verecektir: +ve <literal>server_names_hash_bucket_size</literal> yönergelerini tekrar ayarlamalısınız. <literal>server_names_hash_bucket_size</literal> 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: <programlisting> could not build the server_names_hash, @@ -335,15 +335,15 @@ Düzenli ifade sunucu adları 0.6.7 versiyonundan beri destekleniyor. </listitem> <listitem> -<url>nginx.*</url> wildcard formu 0.6.0 versiyonundan beri destekleniyor. +<url>example.*</url> wildcard formu 0.6.0 versiyonundan beri destekleniyor. </listitem> <listitem> -<url>.nginx.org</url> özel formu 0.3.18 versiyonundan beri destekleniyor. +<url>.example.org</url> özel formu 0.3.18 versiyonundan beri destekleniyor. </listitem> <listitem> -<url>*.nginx.org</url> wildcard formu 0.1.13 versiyonundan beri destekleniyor. +<url>*.example.org</url> wildcard formu 0.1.13 versiyonundan beri destekleniyor. </listitem> </list>