Mercurial > hg > nginx-site
view xml/tr/docs/http/request_processing.xml @ 1942:0227aa9b87de
Removed "experimental" info from js modules.
author | Yaroslav Zhuravlev <yar@nginx.com> |
---|---|
date | Wed, 22 Mar 2017 15:36:18 +0300 |
parents | 130fad6dc1b4 |
children |
line wrap: on
line source
<!DOCTYPE article SYSTEM "../../../../dtd/article.dtd"> <article name="nginx bir talebi nasıl işler" link="/tr/docs/http/request_processing.html" lang="tr" author="Igor Sysoev" translator="Altan Tanrıverdi"> <section name="Ad-tabanlı sanal sunucular"> <para> nginx, ilk olarak hangi sunucunun talebi işleyeceğine karar verir. 80 portunu dinleyen 3 sunucunun olduğu bir yapılandırma ile örnek verelim: <programlisting> server { listen 80; server_name example.org www.example.org; ... } server { listen 80; server_name example.net www.example.net; ... } server { listen 80; server_name example.com www.example.com; ... } </programlisting> </para> <para> Bu yapılandırmada, nginx yalnızca talebin header bilgisinde bulunan “Host” datasını kullanarak hangi sunucunun cevap vereceğini belirliyor. Eğer “Host” datası boş ise veya herhangi bir sunucu adı ile eşleşmez ise nginx talebi varsayılan sunucuya yönlendirir. Yukarıdaki örnekte varsayılan sunucu ilk server ifadesi kabul edilir. Eğer ilk server ifadesinin varsayılan olmasını istemiyorsanız, <literal>listen</literal> yönergesinde <literal>default_server</literal> parametresini kullanabilirsiniz: <programlisting> server { listen 80 <b>default_server</b>; server_name example.net www.example.net; ... } </programlisting> <note> <literal>default_server</literal> parametresi, versiyon 0.8.21 ile birlikte kullanılmaya başlanmıştır. Önceki versiyonlarda <literal>default</literal> parametresi kullanılmalıdır. </note> Not: Varsayılan sunucu, sunucu adının değil listen portunun bir özelliğidir. Daha sonra bu konuya değinilecek. </para> </section> <section id="how_to_prevent_undefined_server_names" name="Tanımlanmamış sunucu adlarına gelen taleplerin işlenmesini engellemek"> <para> Eğer tanımlanmamış “Host” bilgisine sahip talepleri işlemek istemiyorsanız, bu talepleri düşüren bir varsayılan sunucu tanımlayabilirsiniz: <programlisting> server { listen 80 default_server; server_name _; return 444; } </programlisting> Böylece var olmayan alan adı için “_” ifadesini kullanarak nginx’in standart olmayan 444 koduna yönlendirerek bağlantıyı kapatıyoruz. Not: Bu sunucu için bir ad belirlemelisiniz. Aksi takdirde nginx <i>hostname</i> ifadesini kullanacaktır. </para> </section> <section id="mixed_name_ip_based_servers" name="Ad ve IP bazlı karışık sanal sunucular"> <para> 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 example.org www.example.org; ... } server { listen 192.168.1.1:80; server_name example.net www.example.net; ... } server { listen 192.168.1.2:80; server_name example.com www.example.com; ... } </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, <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> 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 example.org www.example.org; ... } server { listen 192.168.1.1:80 default_server; server_name example.net www.example.net; ... } server { listen 192.168.1.2:80 default_server; server_name example.com www.example.com; ... } </programlisting> </para> </section> <section id="simple_php_site_configuration" name="Basit bir PHP sitesi yapılandırması"> <para> 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 example.org www.example.org; root /data/www; location / { index index.html index.php; } location ~* \.(gif|jpg|png)$ { expires 30d; } location ~ \.php$ { fastcgi_pass localhost:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } </programlisting> </para> <para> nginx ilk olarak literal dizgiler (string) tarafından verilmiş en spesifik lokasyonları arar. Yukarıdaki yapılandırmada tek literal lokasyon <path>/</path> ifadesidir ve herhangi bir talep ile eşleştiğinde kullanılacak son uğraktır (resort). nginx, daha sonra yapılandırma dosyasında bulunan listelenmiş sıralardaki düzenli ifadeler tarafından verilmiş lokasyonları arar. İlk düzenli ifade eşleşmesi aramayı durdurur ve nginx bu lokasyonu kullanır. Eğer talep ile eşleşen bir düzenli ifade bulunamaz ise nginx daha önce bulduğu en spesifik lokasyonu kullanır. </para> <para> Not: Tüm tiplerde bulunan bu lokasyonlar sadece bir talebin, sorgu dizgisi olmayan URI datasını test eder. Bunun yapılmasının nedeni sorgu dizgisinde bulunan argümanların çeşitli yollarla verilebilmesidir, örneğin: <programlisting> /index.php?user=john&page=1 /index.php?page=1&user=john </programlisting> Ayrıca herhangi biri, herhangi bir şeyi sorgu dizgileri ile talep edebilir: <programlisting> /index.php?page=1&baska+bir+sey&user=john </programlisting> </para> <para> Yukarıdaki yapılandırmada taleplerin nasıl işlendiğini inceleyelim: <list type="bullet"> <listitem> <para> Bir <path>/logo.gif</path> talebi, ilk olarak <literal>/</literal> literal lokasyonu, daha sonra, <literal>\.(gif|jpg|png)$</literal> düzenli ifadesi tarafından eşleştirilir. Bu sonraki (latter) lokasyon tarafından tutulur. <literal>root /data/www</literal> yönergesi kullanılarak, talep <path>/data/www/logo.gif</path> dosyasına eşlemlenir (mapped to) ve dosya istemciye gönderilir. </para> </listitem> <listitem> <para> Bir <path>/index.php</path> talebi de ilk olarak <literal>/</literal> literal lokasyonu, sonra, <literal>\.(php)$</literal> düzenli ifadesi tarafından eşleştirilir. Bu nedenle sonraki lokasyon tarafından tutulur ve localhost:9000’in dinlendiği bir FastCGI sunucusuna iletilir. <literal>fastcgi_param</literal> yönergesi, SCRIPT_FILENAME FastCGI parametresini <path>/data/www/index.php</path> adresine yerleştirir ve FastCGI sunucusu dosyayı yürütür. $document_root değişkeni <literal>root</literal> yönergesinin değerine, $fastcgi_script_name değişkeni ise talebin URI değerine eşittir. Örneğin <path>/index.php</path>. </para> </listitem> <listitem> <para> Bir <path>/about.html</path> talebi yalnızca <literal>/</literal> literal lokasyonu tarafından eşleştirilir ve bu yüzden, bu lokasyon tarafından tutulur. <literal>root /data/www</literal> yönergesi kullanılarak talep, <path>/data/www/about.html</path> dosyasına eşlemlenir ve istemciye gönderilir. </para> </listitem> <listitem> <para> Bir <path>/</path> talebini tutmak daha karmaşıktır. Sadece <literal>/</literal> literal lokasyonu tarafından eşleştirilir ve bu yüzden bu lokasyon tarafından tutulur. Sonra <literal>index</literal> yönergesi parametrelerine ve <literal>root /data/www</literal> yönergesine göre bir index dosyası olup olmadığını kontrol eder. Eğer bir <path>/data/www/index.php</path> dosyası mevcut ise yönerge, <path>/index.php</path> adresine dahili bir yönlendirme yapar ve eğer talep bir istemci tarafından gönderilmiş ise nginx, lokasyonları tekrar arar. Daha önce gördüğümüz gibi, yönlendirilmiş talep en son olarak FastCGI sunucusu tarafından tutulur. </para> </listitem> </list> </para> </section> </article>