2.4.x/docs/manual/mod/core.xml.tr - httpd - Git at Google

 <?xml version="1.0"?>
 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
 <?xml-stylesheet type="text/xsl" href="../style/manual.tr.xsl"?>
 <!-- English Revision: 1772678 -->
 <!-- =====================================================
  Translated by: Nilgün Belma Bugüner <nilgun belgeler.gen.tr>
    Reviewed by: Orhan Berent <berent belgeler.gen.tr>
 ========================================================== -->

 <!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
 -->

 <modulesynopsis metafile="core.xml.meta">

 <name>core</name>
 <description>Apache HTTP Sunucusunda daima mevcut olan çekirdek
  özellikler</description>
 <status>Core</status>

 <directivesynopsis>
 <name>AcceptFilter</name>
 <description>Bir protokolün dinleyici soketleri için en iyilemeleri ayarlar
 </description>
 <syntax>AcceptFilter <var>protocol</var> <var>kabul_süzgeci</var></syntax>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p>Bu yönerge <directive module="core">Protocol</directive> yönergesinde belirtilen
       protokol türüne göre bir dinleme soketinin işletim
       sistemine özgü en iyilemelerini etkin kılar. İşletim sistemi çekirdeği
       için temel önerme veri alınıncaya kadar veya HTTP isteğinin tamamı
       tamponlanana kadar sunucu sürecine bir soket tahsis etmemektir.
       Şimdilik sadece <a
   href="http://www.freebsd.org/cgi/man.cgi?query=accept_filter&amp;sektion=9"
       >FreeBSD’nin Kabul Süzgeçleri</a> ve Linux’un soket seçeneklerinden
       <code>TCP_DEFER_ACCEPT</code> ve Windows'un en iyilenmiş
       <code>AcceptEx()</code> işlevi desteklenmektedir.</p>

     <p>Değiştirge olarak <code>none</code> kullanımı, protokolün kabul
       süzgeçlerini iptal edecektir. <code>ftp:</code> veya <code>nntp</code>
       gibi sunucunun baştan bir veri göndermesinin gerekli olduğu
       protokoller için kullanışlıdır. Örnek:</p>

     <highlight language="config">
 AcceptFilter nntp none
     </highlight>

     <p>Öntanımlı protokol isimleri port 443 için <code>https</code> ve tüm
       diğer portlar için <code>http</code>'dir. Dinlenmesi için başka bir port
       ile ilgili bir protokol belirtmek isterseniz <directive
       module="mpm_common">Listen</directive> yönergesine <var>protokol</var>
       argümanını ekleyin.</p>

     <p>FreeBSD için öntanımlı değerler:</p>
     <highlight language="config">
 AcceptFilter http httpready
 AcceptFilter https dataready
     </highlight>

     <p><code>httpready</code> kabul süzgeci HTTP isteklerinin tamamını
       işletim sistemi çekirdeği seviyesinde tamponlar. Çekirdek isteğin
       tamamını alır almaz sunucuya gönderir. Ayrıntılar için <a
       href="http://www.freebsd.org/cgi/man.cgi?query=accf_http&amp;sektion=9"
       >accf_http(9)</a> kılavuz sayfasına bakınız. HTTPS istekleri
       şifrelenmiş olduğundan sadece <a
       href="http://www.freebsd.org/cgi/man.cgi?query=accf_data&amp;sektion=9"
       >accf_data(9)</a> süzgeci kullanılır.</p>

     <p>Linux’taki öntanımlı değerler:</p>
     <highlight language="config">
 AcceptFilter http data
 AcceptFilter https data
     </highlight>

     <p>Linux’un <code>TCP_DEFER_ACCEPT</code> soket seçeneği HTTP isteklerinin
       tamponlanmasını desteklemez.  <code>none</code> dahil her değer
       dinleyici üzerinde <code>TCP_DEFER_ACCEPT</code> seçeneğini etkin kılar.
       Daha ayrıntılı bilgi edinmek için Linux
       <a href="http://man7.org/linux/man-pages/man7/tcp.7.html"
       >tcp(7)</a> kılavuz sayfasına bakınız.</p>

     <p>Windows’taki öntanımlı değerler::</p>

     <highlight language="config">
 AcceptFilter http connect
 AcceptFilter https connect
     </highlight>

     <p>Windows'un <code>mpm_winnt</code> modülü <code>AcceptEx()</code>
       arayüzünü açıp kapamak için <code>AcceptFilter</code>'i yorumlar ve
       http protokol tamponlamasını desteklemez. <code>connect</code>, <code>AcceptEx()</code> arayüzünü kullanacak, ayrıca uç ağ adresleri de alınacak, fakat <code>none</code> gibi <code>connect</code> seçeneği de ilk veri aktarımını beklemeyecektir.</p>

     <p>Windows'ta <code>none</code> <code>AcceptEx()</code>'ten ziyade
       <code>accept()</code> kullanır ve ağ soketlerini bağlantılar arasında
       yer değiştirmez. Sürücü desteği bozuk ağ bağdaştırıcılarından başka
       vpn sürücüleri gibi bazı sanal ağ sağlayıcılar veya spam, virus veya
       casus yazılım süzgeçleri için kullanışlıdır.</p>

     <note type="warning">
       <title><code>data</code> AcceptFilter (Windows)</title>

       <p>2.4.23 ve öncesi sürümlerde, Windows <code>data</code> accept
          süzgeci veri aktarılana kadar bekletildikten sonra ilk veri
          tamponlanır ve uç ağ adresi için tek bir AcceptEx() çağrısı yapılır.
          Bu gerçeklenim hizmet reddi saldırısına konu olduğundan iptal
          edilmiştir.</p>

       <p>httpd'nin şu anki dağıtımları için Windows'da <code>connect</code>
         süzgeci öntanımlıdır ve <code>data</code> belirtilmiş olsa dahi
         <code>connect</code> belirtilmiş gibi davranılır. Önceki sürümleri
         kullananların AcceptFilter satırını yukarıdaki gibi
         <code>connect</code> süzgecine ayarlamaları gerekmektedir.</p>
     </note>

 </usage>
 <seealso><directive module="core">Protocol</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>AcceptPathInfo</name>
 <description>Dosya isminden sonra belirtilen yol verisini kabul veya
   reddeder.</description>
 <syntax>AcceptPathInfo On|Off|Default</syntax>
 <default>AcceptPathInfo Default</default>
 <contextlist><context>server config</context>
 <context>virtual host</context><context>directory</context>
 <context>.htaccess</context></contextlist>
 <override>FileInfo</override>

 <usage>
     <p>Bu yönerge, istekte dosya isminden sonra (dizinde belirtilen dosya
       bulunmayabilir) belirtilen yol verisinin kabul edilip edilmeyeceğini
       denetler. Dosya isminden sonra belirtilen yol verisi
       <code>PATH_INFO</code> ortam değişkeninde betiklerin kullanımına
       sunulabilir.</p>

     <p>Örneğin, içinde sadece <code>here.html</code> dosyası bulunan bir
       <code>/test/</code> dizinimiz olsun. <code>/test/here.html/more</code>
       ve <code>/test/nothere.html/more</code> isteklerinin her ikisi de
       <code>PATH_INFO</code> değişkenine <code>/more</code> verisinin
       atanmasını sağlar.</p>

     <p><directive>AcceptPathInfo</directive> yönergesine atanabilecek argüman
       sayısı üçtür:</p>
     <dl>
     <dt><code>Off</code></dt><dd>Sadece dosya isminden sonra yol verisi
       bulunmayan istekler kabul edilir. Yukarıdaki örnekteki gibi
       <code>/test/here.html/more</code> şeklindeki istekler bir 404 (Nesne
       bulunamadı) hatasıyla sonuçlanır.</dd>

     <dt><code>On</code></dt><dd>Mevcut bir dosyaya ait bir dosya isminden
       sonra bir yol verisinin de belirtildiği istekler kabul edilir.
       Yukarıdaki örnekteki gibi <code>/test/here.html/more</code> şeklindeki
       istekler, <code>/test/here.html</code> geçerli bir dosya olduğu
       takdirde kabul edilir.</dd>

     <dt><code>Default</code></dt><dd>Dosya isminden sonra yol verisi
       belirtilen isteklerin nasıl ele alınacağı istekten sorumlu <a
       href="../handler.html">eylemci</a> tarafından saptanır. Normal dosyalar
       için çekirdek eylemci öntanımlı olarak <code>PATH_INFO</code>
       isteklerini reddeder. <a
       href="mod_cgi.html"><code>cgi-script</code></a> ve <a
       href="mod_isapi.html"><code>isapi-handler</code></a> gibi betiklere
       hizmet eden eylemciler ise genellikle <code>PATH_INFO</code>
       isteklerini öntanımlı olarak kabul ederler.</dd>
     </dl>

     <p><code>AcceptPathInfo</code> yönergesinin birincil amacı eylemcinin
       <code>PATH_INFO</code> istekleri hakkında verdiği kabul veya red
       kararını geçersiz kılabilmenizi sağlamaktır. Örneğin,
       <code>PATH_INFO</code>’ya dayalı olarak içerik üretmek için <a
       href="mod_include.html"><code>INCLUDES</code></a> gibi bir <a
       href="../filter.html">süzgeç</a> kullandığınız takdirde bu
       geçersizleştirme zorunlu olur. Normal dosyalar için çekirdek eylemci
       normal olarak isteği reddederdi, böyle bir durumda bir betiği etkin
       kılmak için aşağıdaki gibi bir yapılandırma kullanabilirsiniz:</p>

     <highlight language="config">
 &lt;Files "mypaths.shtml"&gt;
   Options +Includes
   SetOutputFilter INCLUDES
   AcceptPathInfo On
 &lt;/Files&gt;
     </highlight>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>AccessFileName</name>
 <description>Dağıtık yapılandırma dosyasının ismi belirtilir.</description>
 <syntax>AccessFileName <var>filename</var> [<var>filename</var>] ...</syntax>
 <default>AccessFileName .htaccess</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p>Belge yolu üzerindeki dizinlerde dağıtık yapılandırma dosyalarının <a
       href="#allowoverride">bulunmasına izin verilmişse</a> sunucu bir isteği
       işlerken önce bu dizinlerde bu yönergede belirtilmiş yapılandırma
       dosyasını arar. Örnek:</p>

     <highlight language="config">
 AccessFileName .acl
     </highlight>

     <p>Sunucu, <code>/usr/local/web/index.html</code> belgesini döndürmeden
       önce,</p>

     <highlight language="config">
 &lt;Directory "/"&gt;
     AllowOverride None
 &lt;/Directory&gt;
     </highlight>

     <p>şeklinde bir yapılandırma ile iptal edilmiş olmadıkça yönergeler için
       <code>/.acl</code>, <code>/usr/.acl</code>,
       <code>/usr/local/.acl</code> ve <code>/usr/local/web/.acl</code>
       dosyalarını okur.</p>
 </usage>
 <seealso><directive module="core">AllowOverride</directive></seealso>
 <seealso><a href="../configuring.html">Yapılandırma Dosyaları</a></seealso>
 <seealso><a href="../howto/htaccess.html">.htaccess Dosyaları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>AddDefaultCharset</name>
 <description>Bir yanıtın içerik türü <code>text/plain</code> veya
   <code>text/html</code> olduğunda eklenecek öntanımlı karakter kümesi
   parametresini belirler.</description>
 <syntax>AddDefaultCharset On|Off|<var>karküm</var></syntax>
 <default>AddDefaultCharset Off</default>
 <contextlist><context>server config</context>
 <context>virtual host</context><context>directory</context>
 <context>.htaccess</context></contextlist>
 <override>FileInfo</override>

 <usage>
     <p>Bu yönerge, yanıtın içerik türü <code>text/plain</code> veya
       <code>text/html</code> olmak şartıyla yanıta eklenecek karakter
       kümesini (karakter kodlamasınının ismini) belirler. Bu, asıl davranış
       çoğunlukla kullanıcının istemci yapılandırmasına bağlı olmakla
       birlikte, yanıtın gövdesinde <code>META</code> elemanı vasıtasıyla
       belirtilmiş karakter kümesini geçersiz kılar. <code>AddDefaultCharset
       Off</code> şeklinde bir atama bu işlevselliği iptal eder.
       <code>AddDefaultCharset On</code> ile bu işlevsellik etkin kılınmaktan
       başka <code>iso-8859-1</code> karakter kümesini öntanımlı olarak yanıta
       eklenir. Yönergede <var>karküm</var> olarak belirtilecek değerler,
       Genel Ağ ortam türlerinde (MIME türlerinde) kullanmak üzere <a
       href="http://www.iana.org/assignments/character-sets">IANA’da kayıtlı
       karakter kümesi değerleri</a>nden biri olmalıdır. Örnek:</p>

     <highlight language="config">
 AddDefaultCharset utf-8
     </highlight>

     <p><directive>AddDefaultCharset</directive> yönergesi sadece, metin
       kaynaklarının hepsinin aynı karakter kümesine sahip olduğu bilindiği
       takdirde ve her birinde ayrı ayrı karakter kümesi belirtmek çok
       külfetli olacaksa kullanılmalıdır. Buna bir örnek, CGI betikleri
       tarafından üretilmiş içeriğe sahip kaynaklara karakter kümesinin
       eklenmesidir; böyle kaynaklar çıktıda kullanıcı tarafından sağlanmış
       veri içermeleri nedeniyle karşı siteden kaynaklanan betikli
       saldırılardan zarar görebilir. Bununla birlikte, bir öntanımlı karakter
       kümesi belirtmek, tarayıcılarında “karakter kodlamasını kendiliğinden
       sapta” özelliğini etkin kılmış kullanıcıları korumayacağından daha iyi
       bir çözüm bu betikleri bu tür saldırılara karşı düzeltmek veya en iyisi
       silmektir.</p>
 </usage>
 <seealso><directive module="mod_mime">AddCharset</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>AllowEncodedSlashes</name>
 <description>Kodlanmış dosya yolu ayracı içeren URL’lere izin verilip
   verilmeyeceğini belirler.</description>
 <syntax>AllowEncodedSlashes On|Off|NoDecode</syntax>
 <default>AllowEncodedSlashes Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>
 <compatibility>NoDecode seçeneği Apache httpd 2.3.12 ve sonrasında
   mevcuttur.</compatibility>

 <usage>
     <p><directive>AllowEncodedSlashes</directive> yönergesi kodlanmış dosya
       yolu ayracı içeren URL’lere izin verir (<code>/</code> yerine
       <code>%2F</code> ve ek olarak <code>\</code> için ilgili sistemlerde
       <code>%5C</code> kullanılmış URL’ler).</p>

     <p><code>Off</code> öntanımlı değeriyle, böyle URL’ler bir 404
       (Nesne bulunamadı) hatasıyla reddedilirler.</p>

     <p><code>On</code> değeriyle, böyle URL’ler kabul edilir ve kodlanmış
       dosya yolu ayraçları kodlanmış diğer karakterler gibi çözümlenir.</p>

     <p><code>NoDecode</code> değeriyle, böyle URL’ler kabul edilir fakat
       kodlanmış dosya yolu ayraçları çözümlenmeden kodlanmış halde
       bırakılır.</p>

     <p><directive>AllowEncodedSlashes</directive> <code>On</code>, çoğunlukla
       <code>PATH_INFO</code> ile bir arada kullanıldığı zaman
       kullanışlıdır.</p>

     <note><title>Ek Bilgi</title>
       <p>Kodlanmış bölü çizgileri yol bilgisi için gerekliyse bir güvenlik
       ölçütü olarak <code>NoDecode</code> kullanımı şiddetle önerilir.
       Kodlanmış bölü çizgilerinin çözümlenmesine izin vermek güvensiz olması
       olası yollara izin vermek olurdu.</p>
     </note>
 </usage>
 <seealso><directive module="core">AcceptPathInfo</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>AllowOverride</name>
 <description><code>.htaccess</code> dosyalarında bulunmasına izin verilen
   yönerge türleri belirtilir.</description>
 <syntax>AllowOverride All|None|<var>yönerge-türü</var>
 [<var>yönerge-türü</var>] ...</syntax>
 <default>AllowOverride None (2.3.9 ve sonrası), AllowOverride All (2.3.8 ve öncesi)</default>
 <contextlist><context>directory</context></contextlist>

 <usage>
     <p>Sunucu <directive module="core">AccessFileName</directive> yönergesi
       ile belirtildiği şekilde bir <code>.htaccess</code> dosyasına rastlarsa
       önceki yapılandırma yönergelerinin hangilerinin geçersiz kılınmak üzere
       bildirildiğini bilmek ister.</p>

     <note><title>Sadece &lt;Directory&gt; bölümlerinde geçerli</title>
       <directive>AllowOverride</directive> yönergesi, <directive
       type="section" module="core">Location</directive>, <directive
       module="core" type="section">DirectoryMatch</directive> veya <directive
       type="section" module="core">Files</directive> bölümlerinde değil,
       sadece düzenli ifade içermeyen <directive type="section"
       module="core">Directory</directive> bölümlerinde geçerlidir.
     </note>

     <p>Bu yönergeye ve <directive module="core">AllowOverrideList</directive>
       yönergesine değer olarak <code>None</code> belirtilirse
       <a href="#accessfilename">.htaccess</a> dosyaları tamamen yok sayılır.
       Bu durumda, sunucu dosya sisteminde rastladığı <code>.htaccess</code>
       dosyalarını okumaya dahi çalışmayacaktır.</p>

     <p>Bu yönergeye <code>All</code> değeri atanırsa, .htaccess <a
       href="directive-dict.html#Context">bağlamında</a> kullanılabilecek her
       yönergeye <code>.htaccess</code> dosyalarında izin verilir.</p>

     <p><code><var>yönerge-türü</var></code> olarak aşağıdaki yönerge grup
       isimlerinden biri belirtilebilir:</p>

     <dl>
       <dt>AuthConfig</dt>

       <dd><directive module="mod_authz_dbm">AuthDBMGroupFile</directive>,
         <directive module="mod_authn_dbm">AuthDBMUserFile</directive>,
         <directive module="mod_authz_groupfile">AuthGroupFile</directive>,
         <directive module="mod_authn_core">AuthName</directive>,
         <directive module="mod_authn_core">AuthType</directive>,
         <directive module="mod_authn_file">AuthUserFile</directive>,
         <directive module="mod_authz_core">Require</directive>
         <em>ve benzeri</em> yetkilendirme yönergelerinin kullanımını izin
         verilir.</dd>

       <dt>FileInfo</dt>

       <dd>Belge türünü denetleyen <module>mod_mime</module>
         <code>Add*</code> ve <code>Remove*</code> yönergeleri,
         <directive module="core">ErrorDocument</directive>,
         <directive module="core">ForceType</directive>,
         <directive module="mod_negotiation">LanguagePriority</directive>,
         <directive module="core">SetHandler</directive>,
         <directive module="core">SetInputFilter</directive>,
         <directive module="core">SetOutputFilter</directive>
         yönergeleri ve benzerleri ile
         <directive module="mod_headers">Header</directive>,
         <directive module="mod_headers">RequestHeader</directive>,
         <directive module="mod_setenvif">SetEnvIf</directive>,
         <directive module="mod_setenvif">SetEnvIfNoCase</directive>,
         <directive module="mod_setenvif">BrowserMatch</directive>,
         <directive module="mod_usertrack">CookieExpires</directive>,
         <directive module="mod_usertrack">CookieDomain</directive>,
         <directive module="mod_usertrack">CookieStyle</directive>,
         <directive module="mod_usertrack">CookieTracking</directive>,
         <directive module="mod_usertrack">CookieName</directive>
         belge meta veri yönergelerinin,
         <module>mod_rewrite</module> modülündeki
         <directive module="mod_rewrite">RewriteEngine</directive>,
         <directive module="mod_rewrite">RewriteOptions</directive>,
         <directive module="mod_rewrite">RewriteBase</directive>,
         <directive module="mod_rewrite">RewriteCond</directive>,
         <directive module="mod_rewrite">RewriteRule</directive>
         yönergelerinin, <module>mod_alias</module> modülündeki
         <directive module="mod_alias">Redirect</directive>,
         <directive module="mod_alias">RedirectTemp</directive>,
         <directive module="mod_alias">RedirectPermanent</directive>,
         <directive module="mod_alias">RedirectMatch</directive>)
         yönergelerinin ve <module>mod_actions</module> modülündeki
         <directive module="mod_actions">Action</directive>
         yönergesinin kullanımına izin verilir.
       </dd>

       <dt>Indexes</dt>

       <dd>Dizin içeriğinin listelenmesini denetleyen
         <directive module="mod_autoindex">AddDescription</directive>,
         <directive module="mod_autoindex">AddIcon</directive>,
         <directive module="mod_autoindex">AddIconByEncoding</directive>,
         <directive module="mod_autoindex">AddIconByType</directive>,
         <directive module="mod_autoindex">DefaultIcon</directive>,
         <directive module="mod_dir">DirectoryIndex</directive>,
         <a href="mod_autoindex.html#indexoptions.fancyindexing"
         ><code>FancyIndexing</code></a>,
         <directive module="mod_autoindex">HeaderName</directive>,
         <directive module="mod_autoindex">IndexIgnore</directive>,
         <directive module="mod_autoindex">IndexOptions</directive>,
         <directive module="mod_autoindex">ReadmeName</directive>
         yönergelerinin <em>ve benzerlerinin</em> kullanımına izin
         verilir.</dd>

       <dt>Limit</dt>

       <dd>Konak erişimini denetleyen
         <directive module="mod_access_compat">Allow</directive>,
         <directive module="mod_access_compat">Deny</directive> ve
         <directive module="mod_access_compat">Order</directive>
         yönergelerinin kullanımına izin verilir.</dd>

       <dt>Nonfatal=[Override|Unknown|All]</dt>

       <dd><a href="#accessfilename">.htaccess</a> dosyalarındaki sözdizimi
         hatalarının ölümcül olarak ele alınmaması için
         <code>AllowOverride</code> yönergesinin kullanımına izin verir; bunun
         yerine bir dahili sunucu hatasına sebep olur, izin verilmeyen veya
         tanınmayan yönergeler yoksayılır ve günlüğe bir uyarı çıktılanır:
         <ul>
           <li><strong>Nonfatal=Override</strong> ile
             <code>AllowOverride</code> tarafından yasaklanmış yönergeler
             ölümcül olarak ele alınmaz.</li>
           <li><strong>Nonfatal=Unknown</strong> ile bilinmeyen yönergeler
             ölümcül olarak ele alınmaz. Yazım hatalarını ve mevcut olmayan bir
             modül tarafından gerçeklenmiş yönergeleri kapsar.</li>
           <li><strong>Nonfatal=All</strong> ile yukarıdakilerin ikisi de
             ölümcül olarak ele alınmaz.</li>
         </ul>
         <p>Geçerli bir yönergedeki yazım hatalarının hala dahili bir sunucu
           hatasına sebep olacağına dikkat ediniz.</p>
         <note type="warning"><title>Güvenlik</title>
           Ölümcül olmayan hatalar <a href="#accessfilename">.htaccess</a>
           kullanıcıları için güvenlikle ilgili sorunlara yol açabilir. Örneğin
           <code>AllowOverride AuthConfig</code>'e izin vermezse kullanıcıların
           siteye erişimini kısıtlayan yapılandırma iptal edilmiş olur.
       </note>
       </dd>

       <dt>Options[=<var>seçenek</var>,...]</dt>

       <dd>Dizinlere özgü özellikleri denetleyen
         <directive module="core">Options</directive> ve
         <directive module="mod_include">XBitHack</directive> yönergelerinin
         kullanımına izin verilir. <directive
         module="core">Options</directive> komutunda belirtilecek seçenekler
         bir eşit işaretinden sonra aralarına sadece virgül konarak,
         fakat virgülden sonra boşluk bırakmadan belirtilebilir.

       <note><title>Options'ın örtük iptali</title>
       <p><a href="#accessfilename">.htaccess</a> dosyalarında kullanılabilen
         seçenek listesi bu yönergeyle sınırlanabilirse de herhangi bir
         <directive module="core">Options</directive> yönergesine izin
         verildiği sürece miras alınmış diğer seçenekler göreli olmayan
         sözdizimi kullanılarak iptal edilebilir. Başka bir deyişle, bu
         mekanizma diğerlerinin değerlerini korumasına izin verirken belli bir
         seçeneği değerini korumaya zorlayamaz.
       </p></note>

       <example>
       AllowOverride Options=Indexes,MultiViews
       </example>
       </dd>
     </dl>

     <p>Örnek:</p>

     <highlight language="config">
 AllowOverride AuthConfig Indexes
     </highlight>

     <p>Bu örnekte <code>AuthConfig</code> ve <code>Indexes</code> grubundaki
       yönergeler bir dahili sunucu hatasına yol açmayacaktır.</p>

     <note><p>Güvenlik ve başarımı arttırmak için
       <code>&lt;Directory "/"&gt;</code>
       bloğu içinde <code>AllowOverride</code> yönergesine <code>None</code>
       dışında bir değer atamayın. Böyle yapmak yerine bir <code>.htaccess</code>
       dosyası yerleştirmeyi düşündüğünüz dizine ait bir
       <code>&lt;Directory&gt;</code> bloğu olması daha iyidir.</p></note>
 </usage>

 <seealso><directive module="core">AccessFileName</directive></seealso>
 <seealso><directive module="core">AllowOverrideList</directive></seealso>
 <seealso><a href="../configuring.html">Yapılandırma Dosyaları</a></seealso>
 <seealso><a href="../howto/htaccess.html">.htaccess Dosyaları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>AllowOverrideList</name>
 <description><code>.htaccess</code> dosyalarında izin verilecek yönergeler tek tek belirtilir</description>
 <syntax>AllowOverrideList None|<var>yönerge</var>
 [<var>yönerge-türü</var>] ...</syntax>
 <default>AllowOverrideList None</default>
 <contextlist><context>directory</context></contextlist>

 <usage>
     <p>Sunucu bir <code>.htaccess</code> dosyası (<directive
       module="core">AccessFileName</directive> tarafından belirtildiği gibi)
       bulduğunda önceki yapılandırma yönergelerini geçersiz kılabilen bu
       dosyada hangi yönergelerin bildirildiğini bilmek ister.</p>

     <note><title>Sadece &lt;Directory&gt; bölümlerinde kullanılabilir</title>
       <directive>AllowOverrideList</directive> sadece <directive
       type="section" module="core">Directory</directive> bölümlerinde düzenli
       ifadeler olmaksızın belirtilmişse kullanılabilir; <directive
       type="section" module="core">Location</directive>, <directive
       module="core" type="section">DirectoryMatch</directive> veya <directive
       type="section" module="core">Files</directive> bölümlerinde değil.
     </note>

     <p>Bu yönergeye ve <directive module="core">AllowOverride</directive>
       yönergesine <code>None</code> atanmışsa
       <a href="#accessfilename">.htaccess</a> dosyaları tamamen yoksayılır. Bu
       durumda sunucu dosya sistemindeki <code>.htaccess</code> dosyalarını
       okumaya bile çalışmayacaktır.</p>

     <p>Örnek:</p>

     <highlight language="config">
 AllowOverride None
 AllowOverrideList Redirect RedirectMatch
     </highlight>

     <p>Yukarıdaki örnekte sadece <code>Redirect</code> ve
       <code>RedirectMatch</code> yönergelerine izin verilmektedir. Tüm
       diğerleri dahili bir sunucu hatasına sebep olacaktır.</p>

     <p>Örnek:</p>

     <highlight language="config">
 AllowOverride AuthConfig
 AllowOverrideList CookieTracking CookieName
     </highlight>

     <p>Yukarıdaki örnekte <directive module="core">AllowOverride
       </directive> yönergesi <code>AuthConfig</code> yönerge grubuna izin
       verirken <directive>AllowOverrideList</directive> yönergesi
       <code>FileInfo</code> yönerge grubundan yalnız iki yönergeye izin
       vermektedir. Tüm diğerleri dahili bir sunucu hatasına sebep
       olacaktır.</p>
 </usage>

 <seealso><directive module="core">AccessFileName</directive></seealso>
 <seealso><directive module="core">AllowOverride</directive></seealso>
 <seealso><a href="../configuring.html">Yapılandırma Dosyaları</a></seealso>
 <seealso><a href="../howto/htaccess.html">.htaccess Dosyaları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>CGIMapExtension</name>
 <description>CGI betik yorumlayıcısını saptama tekniğini belirler.
 </description>
 <syntax>CGIMapExtension <var>cgi-yolu</var> <var>.uzantı</var></syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>Sadece NetWare’de geçerlidir.</compatibility>

 <usage>
     <p>Bu yönerge Apache httpd’nin CGI bekitlerini çalıştırmak için
       kullanacağı yorumlayıcıyı nasıl bulacağını denetlemek için kullanılır.
       Örneğin, <code>CGIMapExtension sys:\foo.nlm .foo</code> satırı
       <code>.foo</code> uzantılı CGI betik dosyalarının FOO yorumlayıcıya
       aktarılmasını sağlar.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>CGIPassAuth</name>
 <description>HTTP yetkilendirme başlıklarının betiklere CGI değişkenleri
 olarak aktarılmasını etkin kılar</description>
 <syntax>CGIPassAuth On|Off</syntax>
 <default>CGIPassAuth Off</default>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>AuthConfig</override>
 <compatibility> Apache HTTP Sunucusunun 2.4.13 ve sonraki sürümlerinde kullanılabilmektedir</compatibility>

 <usage>
     <p><directive>CGIPassAuth</directive> yönergesi, HTTP Temel kimlik
       doğrulamasını gerçekleştiren betikler için gereken
       <code>Authorization</code> gibi HTTP yetkilendirme başlıklarına
       betiklerin erişebilmesini sağlar. Normalde bu HTTP başlıkları
       betiklerden gizli olup sunucuda HTTP Temel kimlik kanıtlaması etkin
       kılındığında sunucuya erişmekte kullanılan kullanıcı kimliklerinin ve
       parolalarının betikler tarafından görülmemesini mümkün kılar. Bu yönerge,
       HTTP Temel kimlik kanıtlamasını betiklerin gerçekleştirmesini sağlamak
       için kullanılmalıdır.</p>

     <p>Apache HTTP Sunucusunun önceki sürümlerinde derleme sırasında
       kullanılabilen <code>SECURITY_HOLE_PASS_AUTHORIZATION</code> sabitinin
       yerine bu yönerge kullanılabilir.</p>

     <p>Bu ayarlama <module>mod_cgi</module>, <module>mod_cgid</module>,
       <module>mod_proxy_fcgi</module>, <module>mod_proxy_scgi</module> ve
       benzerleri gibi <code>ap_add_common_vars()</code> kullanan modüller
       tarafından kabul görür. Özellikle, isteği alışılmış tarzda işleme
       sokmayıp bu arayüzü kullanan modülleri etkiler. Ayrıca,
       <code>ap_add_common_vars()</code> kullanmayan üçüncü parti modüller de
       bu ayarlamayı kullanmayı tercih edebilir.</p>
 </usage>
 </directivesynopsis>

  <directivesynopsis>
 <name>CGIVar</name>
 <description>Bazı CGI değişkenlerinin nasıl atanacağını belirler</description>
 <syntax>CGIVar <var>değişken</var> <var>kural</var></syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>Apache HTTP Server 2.4.21 ve sonrasında kullanılabilir</compatibility>

 <usage>
   <p>Bu yönerge bazı CGI değişkenlerinin nasıl atanacağını belirler.</p>

   <p><strong>REQUEST_URI</strong> kuralları:</p>
   <dl>
     <dt><code>original-uri</code> (default)</dt>
     <dd>Değer özgün istek satırından alınır ve dahili yöneldirmeler veya
     istenen özkaynakları değiştiren alt istekler dikkate alınmaz.</dd>
     <dt><code>current-uri</code></dt>
     <dd>Değer özgün istek satırından farklı olabilecek dahili yönlendirmeleri
     veya istenen özkaynakları değiştiren alt istekleri de yansıtır.</dd>
   </dl>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>ContentDigest</name>
 <description><code>Content-MD5</code> HTTP yanıt başlıklarının üretimini
   etkin kılar.</description>
 <syntax>ContentDigest On|Off</syntax>
 <default>ContentDigest Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>Options</override>
 <status>Experimental</status>

 <usage>
     <p>Bu yönerge RFC2616 ve RFC1864’te tanımlandığı gibi
       <code>Content-MD5</code> üretimini etkin kılar.</p>

     <p>MD5, verideki herhangi bir değişikliğin ileti özetinin değişmesi
       olarak yansıması nedeniyle yüksek derecede itimat sağlayan keyfi
       uzunlukta bir "ileti özeti" (bazen "parmakizi" dendiği de olur)
       hesaplama algoritmasıdır.</p>

     <p><code>Content-MD5</code> başlığı öğe gövdesinin iki uç arasında ileti
       bütünlük sınamasının yapılabilmesini sağlar. Bir istemci veya vekil
       aktarılan öğe gövdesinde rastlantısal bir değişiklik olup olmadığını
       saptamak için bu başlığın doğruluğunu sınayabilir. Başlık örneği:</p>

     <example>
       Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==
     </example>

     <p>Her istekte ileti özeti hesaplanacağından (değerler saklanmaz), bu
       yönergenin sunucunuzda başarım sorunlarına yol açacağına dikkat
       ediniz.</p>

     <p><code>Content-MD5</code>, herhangi bir modül değil, sadece
       <module>core</module> modülü tarafından sunulan belgeler için
       gönderilir. Örneğin, SSI belgeleri CGI betikleri tarafından
       çıktılanırlar ve bayt seviyesinden çıktılar bu başlığa sahip
       olmazlar.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>DefaultRuntimeDir</name>
 <description>Sunucunun çalışma anı dosyaları için temel dizin</description>
 <syntax>DefaultRuntimeDir <var>dizin-yolu</var></syntax>
 <default>DefaultRuntimeDir DEFAULT_REL_RUNTIMEDIR (logs/)</default>
 <contextlist><context>server config</context></contextlist>
 <compatibility>Apache 2.4.2 ve sonrasında kullanılabilmektedir.
 </compatibility>

 <usage>
     <p><directive>DefaultRuntimeDir</directive> yönergesi sunucunun çalışma
       anında oluşturacağı dosyaların (paylaşımlı bellek, kilitler, vb.)
       saklanacağı dizini belirtmekte kullanılır. Göreli bir yol belirtilirse
       tam yol <directive>ServerRoot</directive> yönergesinde belirtilene
       göreli olacaktır.</p>

     <p><strong>Örnek</strong></p>
    <highlight language="config">
 DefaultRuntimeDir scratch/
     </highlight>

     <p><directive>DefaultRuntimeDir</directive> için öntanımlı yer derleme
       sırasında <code>DEFAULT_REL_RUNTIMEDIR</code> #define satırı ile
       değiştirilebilir.</p>

    <p>Bilgi: <directive>ServerRoot</directive> bu yönergeden önce belirtilmiş
      olmalıdır, aksi takdirde temel dizin için öntanımlı
      <directive>ServerRoot</directive> kullanılır.</p>

 </usage>
 <seealso><directive>ServerRoot</directive> üzerindeki izinlerin düzgün olarak
 nasıl ayarlanacağını öğrenmek için:
 <a href="../misc/security_tips.html#serverroot">güvenlik ipuçları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>DefaultType</name>
 <description>Değeri <code>none</code> olduğu takdirde, bu yönergenin bir
 uyarı vermekten başka bir etkisi yoktur. Önceki sürümlerde, bu yönerge,
 sunucunun ortam türünü saptayamadığı durumda göndereceği öntanımlı ortam
 türünü belirlerdi.</description>
 <syntax>DefaultType <var>ortam-türü</var>|none</syntax>
 <default>DefaultType none</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility><code>none</code> değeri Apache httpd 2.2.7 ve sonrasında
 mevcuttur. Diğer tüm seçenekler Apache httpd'nin 2.3.x ve sonraki sürümleri
 için iptal edilmiştir.</compatibility>
 <usage>
   <p>Bu yönerge iptal edilmiştir. Yapılandırma dosyalarının geriye
     uyumluluğunu sağlamak için, öntanımlı bir ortam türünün olmadığını
     belirten <code>none</code> değeriyle belirtilebilir. Örnek:</p>

     <highlight language="config">
 DefaultType None
     </highlight>

     <p><code>DefaultType None</code> sadece httpd-2.2.7 ve sonrasında
       mevcuttur.</p>

     <p>Ortam türlerini dosya uzantıları üzerinden yapılandırmak için
       <directive module="mod_mime">AddType</directive> yönergesini ve
       <code>mime.types</code> yapılandırma dosyasını veya belli özkaynak
       türleri için ortam türlerini yapılandırmak için <directive
       module="core">ForceType</directive> yönergesini kullanın.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>Define</name>
 <description>Bir değişken tanımlar</description>
 <syntax>Define <var>değişken-ismi</var> [<var>değişken-değeri</var>]</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context></contextlist>

 <usage>
     <p>Tek değiştirgeli biçemi <program>httpd</program>’yi <code>-D</code>
       seçeneğiyle çalıştırmaya eşdeğerdir. Bu yönerge, başlatma betiğinde
       <code>-D</code> seçeneğinin argümanlarını değiştirme gereği duymaksızın
       <directive module="core" type="section">IfDefine</directive> bölümlerini
       kullanıma sokmak için kullanılabilir.</p>

     <p>Buna ek olarak, ikinci değiştirge belirtilirse yapılandırma değişkenine
       bu değer atanır. Değişken yapılandırmada <code>${VAR}</code> sözdizimi
       ile kullanılabilir. Değişken daima küresel olarak tanımlı olup
       yapılandırma bölümünü sarmalayan etki alanı ile sınırlanmaz.</p>

     <highlight language="config">
 &lt;IfDefine TEST&gt;
   Define servername test.example.com
 &lt;/IfDefine&gt;
 &lt;IfDefine !TEST&gt;
   Define servername www.example.com
   Define SSL
 &lt;/IfDefine&gt;
 DocumentRoot "/var/www/${servername}/htdocs"
     </highlight>

     <p><directive module="mod_rewrite">RewriteMap</directive> sözdizimi ile
       karışmalardan kaçınmak için değişken isimleri ikinokta ":" karakterleri
       içeremez.</p>

     <p>Bu yönerge sanal konakta ve dizin içeriğinde desteklenirken yapılan
       değişiklikler (eşleşsin eşleşmesin) yönergeyi sarmalayan yapılandırma
       bölümünün ötesinde, sonraki yapılandırma yönergelerine de görünür olur. Diğer
       yapılandırma bölümleri için sağlanan bu desteğe bu yönergenin ilk
       gerçekleniminde hatalı olarak izin verilmişti. Geriye uyumluluk amacıyla
       (önceden sezilmeyen sonuçlarıyla) bu durum muhafaza edilmiştir.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>Directory</name>
 <description>Sadece ismi belirtilen dosya sistemi dizininde ve bunun
   altdizinlerinde ve bunların içeriğinde uygulanacak bir yönerge grubunu
   sarmalar.</description>
 <syntax>&lt;Directory <var>dizin-yolu</var>&gt;
 ... &lt;/Directory&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive type="section">Directory</directive> ve
       <code>&lt;/Directory&gt;</code> sadece ismi belirtilen dosya sistemi
       dizininde, bunun altdizinlerinde ve bu dizinlerin içindeki dosyalara
       uygulanacak bir yönerge grubunu
       sarmalamakta kullanılır. Bir dizin bağlamında kullanılabilecek her
       yönergeye izin verilir. <var>dizin-yolu</var> bir dizinin tam yolu
       olabileceği gibi Unix kabuk tarzı bir dosya ismi eşleştirme kalıbı da
       olabilir. Kalıp dizgesinde, <code>?</code> herhangi bir tek karakterle,
       <code>*</code> herhangi bir karakter dizisiyle eşleşir. Ayrıca
       <code>[]</code> karakter aralıkları da kullanılabilir. ‘/’ karakteri
       ile hiçbir kalıp karakteri eşleşmez, bu bakımdan <code>&lt;Directory
       "/*/public_html"&gt;</code> ile <code>/home/user/public_html</code>
       değil, ama <code>&lt;Directory "/home/*/public_html"&gt;</code>
       eşleşecektir. Örnek:</p>

     <highlight language="config">
 &lt;Directory "/usr/local/httpd/htdocs"&gt;
   Options Indexes FollowSymLinks
 &lt;/Directory&gt;
     </highlight>

     <p>Dizin yollarında isterseniz önceleme kullanabilirsiniz, ancak eğer yol
       bazı boşluklar içeriyorsa mutlaka kullanmanız gerekir. Bir boşluk aksi
       belirtilmedikçe bir ifadenin sonunu belirlediğinden bu gereklidir.</p>

     <note>
       <p><var>dizin-yolu</var> argümanlarını belirtirken dikkatli
         olmalısınız: Apache httpd’nin dosyalara erişmekte kullandığı dosya
         sistemi yolu ile bire bir eşleşmelidir. Belli bir
         <code>&lt;Directory&gt;</code> dizinine uygulanan yönergeler, aynı
         dizine farklı bir yoldan, örneğin başka bir sembolik bağ üzerinden
         erişilen dosyalara uygulanmayacaktır.</p>
     </note>

     <p><code>~</code> karakterine ek olarak <glossary ref="regex">düzenli
       ifadeler</glossary> de kullanılabilir. Örnek:</p>

     <highlight language="config">
 &lt;Directory ~ "^/www/[0-9]{3}"&gt;

 &lt;/Directory&gt;
 </highlight>

     <p>yönergesi <code>/www/</code> içindeki üç rakamdan oluşan dizinlerle
       eşleşecektir.</p>

     <p>Eğer çok sayıda (düzenli ifade olmayan) <directive
       type="section">Directory</directive> bölümü, bir dosyayı içeren bir
       dizinle veya üst dizinlerinden biri ile eşleşiyorsa, uygulama en kısa
       eşleşmedeki yönergelerden başlayarak <a
       href="#accessfilename">.htaccess</a> dosyalarındaki yönergelere kadar
       genişletilir. Örneğin,</p>

     <highlight language="config">
 &lt;Directory "/"&gt;
   AllowOverride None
 &lt;/Directory&gt;

 &lt;Directory "/home"&gt;
   AllowOverride FileInfo
 &lt;/Directory&gt;
     </highlight>

     <p>bölümleri ile <code>/home/web/dir/doc.html</code> belgesine erişirken
       şu aşamalardan geçilir:</p>

     <ul>
       <li><code>AllowOverride None</code> yönergesi uygulanır
         (<code>.htaccess</code> dosyaları iptal edilir).</li>

       <li><code>AllowOverride FileInfo</code> yönergesi uygulanır
         (<code>/home</code> dizini için).</li>

       <li>Sırayla <code>/home/.htaccess</code>,
         <code>/home/web/.htaccess</code> ve
         <code>/home/web/dir/.htaccess</code> dosyaları içindeki
         <code>FileInfo</code> yönergeleri uygulanır.</li>
     </ul>

     <p>Normal bölümlerin tamamı uygulanıncaya kadar düzenli ifadeler
       değerlendirilmez. Düzenli ifadelerin tamamı yapılandırma dosyasında
       görüldükleri sıraya göre sınanırlar. Örneğin,</p>

     <highlight language="config">
 &lt;Directory ~ "abc$"&gt;
   # ... yönergeler burada ...
 &lt;/Directory&gt;
     </highlight>

     <p>düzenli ifadeli bölümü, tüm normal <directive
       type="section">Directory</directive> bölümleri ve
       <code>.htaccess</code> dosyaları uygulanıncaya kadar
       değerlendirilmeyecektir. Düzenli ifadeleri değerlendirmeye sıra gelince
       düzenli ifade <code>/home/abc/public_html/abc</code> ile eşleştirilecek
       ve buna ilişkin <directive type="section">Directory</directive>
       uygulanacaktır.</p>

    <p><strong><code>&lt;Directory "/"&gt;</code> için öntanımlı erişimin tüm
      erişime izin vermek oluşuna dikkat ediniz. Bunu şöyle bir blokla
      değiştirmeniz,</strong></p>

     <highlight language="config">
 &lt;Directory "/"&gt;
   Require all denied
 &lt;/Directory&gt;
     </highlight>

     <p><strong>ve erişilebilir olmasını istediğiniz dizinleri ayrıca
       belirtmeniz önerilir. Daha ayrıntılı bilgi edinmek için <a
       href="../misc/security_tips.html">Güvenlik İpuçları</a> belgesine
       bakınız.</strong></p>

     <p>Dizin bölümleri <code>httpd.conf</code> dosyasında yer alır.
       <directive type="section">Directory</directive> yönergeleri iç içe
       olamazlar ve bir <directive module="core"
       type="section">Limit</directive> veya <directive module="core"
       type="section">LimitExcept</directive> bölümü içinde bulunamazlar.</p>
 </usage>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>DirectoryMatch</name>
 <description>Bir düzenli ifade ile eşleşen dosya sistemi dizinlerinin içeriklerine uygulanacak bir yönerge grubunu sarmalar.</description>
 <syntax>&lt;DirectoryMatch <var>düzifd</var>&gt;
 ... &lt;/DirectoryMatch&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive type="section">DirectoryMatch</directive> and
     <code>&lt;/DirectoryMatch&gt;</code> yönergeleri <directive
       module="core" type="section">Directory</directive> gibi sadece ismi
       belirtilen dosya sistemi dizininde ve içindeki dosyalarda uygulanacak
       bir yönerge grubunu sarmalamakta kullanılır. Tek farkla argüman olarak
       bir <glossary ref="regex">düzenli ifade</glossary> alır. Örnek:</p>

     <highlight language="config">
 &lt;DirectoryMatch "^/www/(.+/)?[0-9]{3}/"&gt;
     # ...
 &lt;/DirectoryMatch&gt;
     </highlight>

     <p>yönergesi <code>/www/</code> içindeki (veya alt dizinlerindeki) üç
       rakamdan oluşan dizinlerle eşleşecektir.</p>

    <note><title>Uyumluluk</title>
       2.3.9 öncesinde, bu yönerge örtük olarak (<directive module="core"
       type="section">Directory</directive> gibi) alt dizinlere de uygulanırdı
       ve satır sonu simgesi ($) ile eşleşemezdi. 2.3.9 ve sonrasında, sadece
       ifade ile eşleşen dizinler sarmalanan yönerge grubundan etkilenmektedir.
     </note>

     <note><title>Sondaki bölü çizgileri</title>
       Bu yönerge bir bölü çizgisi ile sonlanan veya sonlanmayan dizinler için
       yapılan isteklere uygulanır, dolayısıyla satır sonuna ($) çıpalanmış
       ifadeler dikkatli yazılmalıdır.
     </note>

     <p>2.4.8 itibariyle, isimli gruplar ve geriye başvurular elde edilmekte
       olup ilgili isim büyük harfe çevrildikren sonra "MATCH_" ile
       öncelendikten sonra ortama yazılmaktadır. Böylece yol elemanlarına
       <module>mod_rewrite</module> gibi modüllerden veya <a
       href="../expr.html">düzenli ifadelerden</a> başvurmak mümkün
       kılınmıştır. Karışıklığı önlemek için, numaralı (isimsiz) geriye
       başvurular yoksayılmaktadır. Bunların yerine isimli geriye başvurular
       kullanılmalıdır.</p>

       <highlight language="config">
 &lt;DirectoryMatch "^/var/www/combined/(?&lt;sitename&gt;[^/]+)"&gt;
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 &lt;/DirectoryMatch&gt;
       </highlight>
 </usage>
 <seealso>Normal <directive type="section">Directory</directive>
   bölümlerindeki yönergelerle düzenli ifadelerin nasıl karıştırıldığının bir
   açıklaması için <directive type="section"
   module="core">Directory</directive> yönergesine bakınız.</seealso>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>DocumentRoot</name>
 <description>İstemciye görünür olan ana belge ağacının kök dizinini belirler.</description>
 <syntax>DocumentRoot <var>dizin-yolu</var></syntax>
 <default>DocumentRoot "/usr/local/apache/htdocs"</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p>Bu yönerge <program>httpd</program> tarafından dosyalarının sunulacağı
       dizini belirler. <directive module="mod_alias">Alias</directive>
       benzeri bir yönerge ile eşleşmedikçe, sunucu istenen URL’deki yolu,
       belge yolu haline getirmek için belge kök dizinine ekler. Örnek:</p>

     <highlight language="config">
 DocumentRoot "/usr/web"
     </highlight>

     <p>yapılandırması ile <code>http://my.example.com/index.html</code>
       isteği <code>/usr/web/index.html</code> ile eşleştirilir.
       <var>dizin-yolu</var> ile göreli dosya yolu belirtildiği takdirde belge
       kök dizininin <directive  module="core">ServerRoot</directive> ile
       belirtilen sunucu kök dizinine göre belirtildiği varsayılır.</p>

     <p><directive>DocumentRoot</directive> ile belirtilen dizin bir bölü
       çizgisi ile bitirilmemelidir.</p>
 </usage>
 <seealso><a href="../urlmapping.html#documentroot">URL’lerin Dosya Sistemi
   ile Eşlenmesi</a></seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>Else</name>
 <description>Önceki bir <directive type="section" module="core">If</directive> veya <directive type="section" module="core">ElseIf</directive> bölümünün koşulu, çalışma anında bir istek tarafından yerine getirilmediği takdirde uygulanacak yönergeleri içerir</description>
 <syntax>&lt;Else&gt; ... &lt;/Else&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive type="section">Else</directive> sadece ve sadece aynı etki
       alanındaki en son <directive type="section">If</directive> veya
       <directive type="section">ElseIf</directive> bölümü uygulanmamışsa
       kapsadığı yönergeleri uygular. Örneğin:</p>

     <highlight language="config">
 &lt;If "-z req('Host')"&gt;
   # ...
 &lt;/If&gt;
 &lt;Else&gt;
   # ...
 &lt;/Else&gt;
     </highlight>

     <p>Burada, <directive type="section">If</directive> yönergesi
       <var>Host:</var> başlıksız HTTP/1.0 istekleriyle eşleşirken  <directive
       type="section">Else</directive>  <var>Host:</var> başlıklılarla
       eşleşir.</p>

 </usage>
 <seealso><directive type="section" module="core">If</directive></seealso>
 <seealso><directive type="section" module="core">ElseIf</directive></seealso>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.
     <directive type="section">If</directive>,
     <directive type="section">ElseIf</directive> ve
     <directive type="section">Else</directive> son olarak uygulanır.</seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>ElseIf</name>
 <description>İçerdiği koşulun bir istek tarafınan sağlandığı ancak daha önceki bir <directive type="section" module="core">If</directive> veya
 <directive type="section">ElseIf</directive> bölümlerininkilerin sağlanmadığı durumda kapsadığı yönergelerin uygulanmasını sağlar</description>
 <syntax>&lt;ElseIf <var>ifade</var>&gt; ... &lt;/ElseIf&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive type="section">ElseIf</directive> kapsadığı yönergeleri
       sadece ve sadece belirtilen koşulun doğrulandığı ancak aynı etki
       alanında hemen önceki <directive type="section">If</directive> veya
       <directive type="section">ElseIf</directive> yönergesinin uygulanmadığı
       takdirde uygular. Örnek:</p>

     <highlight language="config">
 &lt;If "-R '10.1.0.0/16'"&gt;
   #...
 &lt;/If&gt;
 &lt;ElseIf "-R '10.0.0.0/8'"&gt;
   #...
 &lt;/ElseIf&gt;
 &lt;Else&gt;
   #...
 &lt;/Else&gt;
     </highlight>

     <p><directive type="section">ElseIf</directive> bir isteğin uzak adresi
       10.0.0.0/8 ağına aitse ama 10.1.0.0/16 ağına ait değilse içerdiği
       yönergelerin uygulanmasını sağlar.</p>

 </usage>
 <seealso>Tam bir kaynak ve daha fazla örnek için: <a href="../expr.html">Apache HTTP Sunucusundaki ifadeler</a></seealso>
 <seealso><directive type="section" module="core">If</directive></seealso>
 <seealso><directive type="section" module="core">Else</directive></seealso>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.
   <directive type="section">If</directive>,
   <directive type="section">ElseIf</directive> ve
   <directive type="section">Else</directive> son olarak uygulanır.</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>EnableMMAP</name>
 <description>Teslimat sırasında okunacak dosyalar için bellek eşlemeyi etkin
   kılar.</description>
 <syntax>EnableMMAP On|Off</syntax>
 <default>EnableMMAP On</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility><code>none</code> değeri Apache 2.2.7 ve sonrasında mevcuttur.
 </compatibility>
 <usage>
     <p>Bu yönerge, sunucunun teslimat sırasında gerektiği takdirde bir dosya
       içeriğinin okunması için bellek eşleme kullanıp kullanmayacağını
       belirler. Öntanımlı olarak, bir isteğin yerine getirilmesi,
       <module>mod_include</module> kullanarak sunucu tarafından çözümlenen
       bir dosyanın teslimatı sırasında olduğu gibi, bir dosya içindeki veriye
       erişilmesini gerektirdiğinde Apache httpd, işletim sistemi tarafından
       desteklendiği takdirde dosyayı belleğe eşler.</p>

     <p>Böyle bellek eşleme kimi zaman başarım artışını beraberinde getirirse
       de bazen sorunlardan kaçınmak için bellek eşlemeyi kapatmak daha iyi
       sonuç verir:</p>

     <ul>
     <li>Bazı çok işlemcili sistemlerde bellek eşleme
       <program>httpd</program>’nin başarımını düşürebilmektedir.</li>
     <li><program>httpd</program> bellek eşlemli çalışırken bir dosyanın
       silinmesi veya boyutunun küçültülmesi <program>httpd</program>'nin
       parçalama arızası vererek çökmesine yol açabilir.</li>
     </ul>

     <p>Bu tür sorunlardan dolayı zarar görülebilecek sunucu
       yapılandırmalarında dosya teslimatında bellek eşlemlerinin kullanımını
       şu şekilde iptal etmeniz gerekir:</p>

     <highlight language="config">
 EnableMMAP Off
     </highlight>

     <p>Bu özellik, sadece NFS dosya sistemi üzerinde sunulan dosyaları
       kapsamak üzere şu şekilde kolayca kapatılabilir:</p>

     <highlight language="config">
 &lt;Directory "/nfs-dosyaları-yolu"&gt;
   EnableMMAP Off
 &lt;/Directory&gt;
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>EnableSendfile</name>
 <description>Dosyaların istemciye tesliminde çekirdeğin dosya gönderme
   desteğinin kullanımını etkin kılar.</description>
 <syntax>EnableSendfile On|Off</syntax>
 <default>EnableSendfile Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>Öntanımlı değer 2.3.9 sürümünde Off olarak değişti.</compatibility>

 <usage>
     <p>Bu yönerge, dosya içeriğinin istemciye teslimi için
       <program>httpd</program>’nin çekirdeğin dosya gönderme desteğini
       kullanıp kullanmayacağını belirler. Öntanımlı olarak, bir isteğin
       yerine getirilmesi, bir durağan dosyanın teslimatı sırasında olduğu
       gibi, bir dosya içindeki veriye erişilmesini gerektirmediği takdirde
       Apache httpd, işletim sistemi tarafından destekleniyorsa dosyayı
       istemciye teslim etmek için çekirdeğin dosya gönderme özelliğini
       kullanır.</p>

     <p>Çekirdeğin dosya gönderme mekanizması, okuma, gönderme ve tampon
       ayırma işlemlerini ayrı ayrı yapmaktan kaçınır. Fakat bazı
       platformlarda veya bazı dosya sistemlerinde aşağıda belirtilen işlemsel
       sorunlardan kaçınmak için bu özelliği iptal etmek daha iyidir:</p>

     <ul>
     <li>Bazı platformlar,  derleme sistemince saptanamayan bozuk bir dosya
       gönderme desteğine sahiptir; özellikle eğer derleme işlemi dosya
       gönderme desteğinde sorun olmayan bir makinede yapılıp çalıştırılabilir
       dosyaların sorunlu makineye kurulduğu durumda bu saptama
       yapılamayacaktır.</li>
     <li>Linux’ta IPv6 kullanırken dosya gönderme desteği bazı ağ
       kartlarındaki TCP toplama sağlaması aktarım hatasını tetikler.</li>
     <li>Itanium üzerinde çalışan Linux’ta dosya gönderme desteği
       (<code>sendfile</code>) 2GB’tan büyük dosyalarla çalışamamaktadır.</li>
     <li><directive module="core">DocumentRoot</directive> ağ dosya sistemi
       (NFS, SMB, CIFS, FUSE gibi) üzerinde olduğu durumda çekirdek ağ
       dosyalarını kendi arabelleği üzerinden sunamayabilir.</li>
     </ul>

     <p>Bu sorunlardan muzdarip sunucu yapılandırmaları için bu özelliği şöyle
       etkin kılabilirsiniz:</p>

     <highlight language="config">
 EnableSendfile On
     </highlight>

     <p>Bu özellik, sadece bir ağ dosya sistemi üzerinde sunulan
       dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:</p>

     <highlight language="config">
 &lt;Directory "/nfs-dosyaları-yolu"&gt;
   EnableSendfile Off
 &lt;/Directory&gt;
     </highlight>

 <p><directive>EnableSendfile</directive> yönergesinin .htaccess ve
       diziniçi yapılandırmalarının <module>mod_cache_disk</module> tarafından
       desteklenmediğini lütfen aklınızdan çıkarmayın.
       <directive>EnableSendfile</directive> yönergesinin sadece küresel
       tanımları hesaba katılır.</p>
 </usage>
 </directivesynopsis>

  <directivesynopsis>
 <name>HttpProtocolOptions</name>
 <description>HTTP İstek İletilerindeki sınırlamalarda değişiklik yapar</description>
 <syntax>HttpProtocolOptions [Strict|Unsafe] [RegisteredMethods|LenientMethods]
  [Allow0.9|Require1.0]</syntax>
 <default>HttpProtocolOptions Strict LenientMethods Allow0.9</default>
 <contextlist><context>server config</context>
 <context>virtual host</context></contextlist>
 <compatibility>2.2.32 veya 2.4.24 ve sonrası</compatibility>

 <usage>
     <p>Bu yönerge HTTP istek satırına
       (<a href="https://tools.ietf.org/html/rfc7230#section-3.1.1"
        >RFC 7230 &sect;3.1.1</a>) ve the HTTP istek başlığı alanlarına
       (<a href="https://tools.ietf.org/html/rfc7230#section-3.2"
        >RFC 7230 &sect;3.2</a>) uygulanmış kuralları öntanımlı olarak veya
       <code>Strict</code> seçeneği kullanılarak  değiştirir. Eski modüller,
       uygulamalar veya kullanımı önerilmeyen özel istemciler için eski davranışlara
       dönmeyi sağlamak üzere <code>Unsafe</code> seçeneği eklenmiştir. Bu kurallar
       istek işlenmeden önce uygulanır. Dolayısıyla yönerge, ana bölümde veya
       öntanımlı (ilk) eşleşen sanal konak bölümünde yapılandırılmalıdır.</p>

     <p>Bu yönerge devreye girmeden önce, Apache HTTP Sunucusunun istek iletisi
       ayrıştırıcıları protokolle uyumlu olmayan bir dizi girdi şekline
       toleranslıydı. <a href="https://tools.ietf.org/html/rfc7230#section-9.4"
       >RFC 7230 &sect;9.4 İstek bölme</a> ve
       <a href="https://tools.ietf.org/html/rfc7230#section-9.5"
       >&sect;9.5 Yanıt kaçırma</a> çağrıları uyumsuz istek iletilerinin kabulündeki
       olası risklerden yalnızca iki tanesidir.
       <a href="https://tools.ietf.org/html/rfc7230#section-3.5">RFC 7230
       &sect;3.5</a> "İleti Ayrıştırma Sağlamlığı" belirsiz boşlukların kabul ve
       istek iletisi biçimleme risklerini tanımlar. Bu yönergenin devreye girmesini
       takiben belirtimin tüm imla kurallarına öntanımlı <code>Strict</code> işlem
       kipi ve 3.5 bölümünde tavsiye edilen hoşgörüsüz boşluk uygulanır ve esnekliğe
       müsamaha edilmez.</p>

     <p>Kullanıcılar, özellikle dışa bakan, herkes tarafından erişilebilen sunucu
       konuşlandırmalarında  <code>Unsafe</code> işlem kipine geçiş yapmaya karşı
       kesinlikle uyarılır. Eğer bir arayüz hataları izlemek veya bir intranette
       çalışan özel hizmet tüketicileri için gerekliyse, kullanıcılar, sadece,
       dahili özel ağlarına hizmet etmek üzere yapılandırılmış özel bir sanal konak
       üzerinde <code>Unsafe</code> işlem kipine geçiş yapmalıdır.</p>

     <p><directive>LogLevel</directive> <code>debug</code> seviyesiyle
       yapılandırılmış <directive>ErrorLog</directive> ile kaydedilmiş günlüklerin
       gözden geçirilmesi, böyle hatalı isteklerin kaynaklandıkları yerle birlikte
       belirlenmesine yardımcı olabilir. Kullanıcılar, beklenmedik bir şekilde
       reddedilmiş geçersiz istekleri bulmak için erişim günlüklerindeki 400
       yanıtlarına özellikle dikkat etmelidir.</p>

     <p><a href="https://tools.ietf.org/html/rfc7231#section-4.1">RFC 7231
       &sect;4.1</a> "İstek Yöntemleri" "Genel Bakış" bölümlerinde bir istek
       satırında desteklenmeyen bir yöntem saptadığında özgün sunucuların bir
       hatayla yanıt vermesini gerekli görmüştür. <code>LenientMethods</code>
       seçeneği kullanıldığında olan zaten budur. <code>RegisteredMethods</code>
       seçeneğine geçiş yapmak isteyen yöneticiler
       <directive>RegisterHttpMethod</directive> yönergesini kullanarak standart
       olmayan yöntemleri belirlemelidir. Özellikle <code>Unsafe</code> seçeneğine
       geçiş yapılacaksa bu yol izlenmelidir. Özgün sunucunun kullandığı yöntemleri
       vekil sunucu bilemeyeceği için ileri vekil konaklarda
       <code>RegisteredMethods</code> seçeneğine geçiş yapılmamalıdır.</p>

     <p><a href="https://tools.ietf.org/html/rfc2616#section-19.6">RFC 2616
       &sect;19.6</a> "Önceki Sürümlerle Uyumluluk" bölümünde HTTP sunucularının
       eski HTTP/0.9 isteklerini desteklemesi tavsiye edilmektedir. RFC 7230
       "HTTP/0.9 isteklerini destekleme beklentisi kaldırılmıştır." cümlesiyle bunu
       geçersiz kılmış ve <a href="https://tools.ietf.org/html/rfc7230#appendix-A"
       >RFC 7230 Ek A</a> bölümünde bununla ilgili yorumlar yer almıştır.
       <code>Require1.0</code> seçeneği kullanıcıya öntanımlı <code>Allow0.9</code>
       seçeneğinin davranışına verilen desteği kaldırma imkanını vermektedir.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>Error</name>
 <description>Özel bir hata iletisiyle yapılandırma çözümlemesini durdurur</description>
 <syntax>Error <var>ileti</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <compatibility>2.3.9 ve sonrası</compatibility>

 <usage>
     <p>Yapılandırmada bir hatanın saptanması istenirse, bu yönerge
       yapılandırma çözümlemesinin durdurulması ve özel bir hata iletisi
       üretilmesi için kullanılabilir. Genelde kullanıldığı durum, gerekli
       modüllerin yapılandırmada bulunmadığının raporlanmasıdır.</p>

     <highlight language="config">
 # Örnek
 # mod_include yüklü değilse bilelim
 &lt;IfModule !include_module&gt;
   Error "Hata: mod_include mod_foo için gerekiyor. LoadModule ile yükleyin."
 &lt;/IfModule&gt;

 # SSL veya NOSSL tanımlı mı bilelim
 &lt;IfDefine SSL&gt;
 &lt;IfDefine NOSSL&gt;
   Error "Ne SSL ne de NOSSL tanımlı. Sadece biri tanımlı olsa yeter."
 &lt;/IfDefine&gt;
 &lt;/IfDefine&gt;
 &lt;IfDefine !SSL&gt;
 &lt;IfDefine !NOSSL&gt;
   Error "Ya SSL ya da NOSSL tanımlı olmalı."
 &lt;/IfDefine&gt;
 &lt;/IfDefine&gt;
     </highlight>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>ErrorDocument</name>
 <description>Bir hata durumunda sunucunun istemciye ne döndüreceğini
   belirler.</description>
 <syntax>ErrorDocument <var>hata-kodu</var> <var>belge</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>

 <usage>
     <p>Bir sorun çıktığında veya hata oluştuğunda Apache httpd şu dört
       işlemden birini yapacak şekilde yapılandırılabilir:</p>

     <ol>
       <li>Yerleşik bir hata iletisi çıktılanır.</li>

       <li>Özel bir ileti çıktılanır.</li>

       <li>Sorunu/hatayı işleyecek yerel bir <var>URL-yoluna</var> dahili bir
         yönlendirme yapılır.</li>

       <li>Sorunu/hatayı işleyecek harici bir <var>URL-yoluna</var>
         yönlendirme yapılır.</li>
     </ol>

     <p>İlk seçenek öntanımlıdır. Diğer üç seçenek
       <directive>ErrorDocument</directive> yönergesinin argümanları (hata
       kodundan sonra bir URL veya hata iletisi) ile belirtilir. Apache httpd
       bazı durumlarda sorun/hata ile ilgili ek bilgi verecektir.</p>

     <p>2.4.13 itibariyle, özdevinimli dizgeler ve URLler üretmek için yönerge
       içinde <a href="../expr.html">ifade sözdizimi</a> kullanılabilir.</p>

     <p>URL’ler yerel yollarda (<directive
       module="core">DocumentRoot</directive>’a göre) bir bölü çizgisi (/) ile
       başlatılabileceği gibi istemci tarafından çözümlenecek tam bir URL
       şeklinde de belirtilebilir. Bunlar yerine, tarayıcıda gösterilmek üzere
       bir ileti de belirtilebilir. Örnekler:</p>

     <highlight language="config">
 ErrorDocument 500 http://example.com/cgi-bin/server-error.cgi
 ErrorDocument 404 /errors/bad_urls.php
 ErrorDocument 401 /subscription_info.html
 ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."
 ErrorDocument 403 /errors/forbidden.pl?referrer=%{escape:%{HTTP_REFERER}}
     </highlight>

     <p>Bunlardan başka, Apache httpd’nin kendi hata iletilerinin kullanılacağı
       özel <code>default</code> değeri ile belirtilebilir. Normal şartlar
       altında gerekmese de, bir şey belirtilmediği takdirde mevcut bir
       <directive>ErrorDocument</directive> yönergesini miras alan
       yapılandırmalarda Apache httpd’nin kendi hata iletilerinin kullanımı
       <code>default</code> değeri açıkça belirtilerek örnekteki gibi
       zorlanabilir:</p>

     <highlight language="config">
 ErrorDocument 404 /cgi-bin/bad_urls.pl

 &lt;Directory "/web/docs"&gt;
   ErrorDocument 404 default
 &lt;/Directory&gt;
     </highlight>

     <p><directive>ErrorDocument</directive> yönergesinde bir uzak URL (önünde
       <code>http</code> bulunan bir yol) belirtildiğinde, belge aynı sunucuda
       olsa bile, Apache HTTP Sunucusunun istemciye belgeyi bulacağı yer için bir
       yönlendirme göndereceğine dikkat ediniz. Bunun bazı istenmeyen etkileri
       vardır; en önemlilerinden biri istemcinin hata kodu yerine bir
       yönlendirme durum kodu alacak olmasıdır. Bu, bir URL’nin geçerliliğini
       durum koduna göre saptayan istemciler veya robotlar için yanıltıcı
       olacaktır. Buna ek olarak, <code>ErrorDocument 401</code> için bir uzak
       URL belirttiğiniz durumda istemci 401 durum kodunu almayacağı için
       kullanıcıdan parola isteğinde bulunamayacaktır. Bu bakımdan,
       <strong>ihtiyaç duyduğunuz takdirde, <code>ErrorDocument 401</code>
       yönergesine yerel bir belge belirtmelisiniz.</strong></p>

     <p>Sunucunun ürettiği hata iletileri "çok kısa" olduğu takdirde,
       Microsoft Internet Explorer (MSIE) öntanımlı olarak bu hata iletilerini
       yoksayar ve bunun yerine kendi "kullanıcı dostu" hata iletilerini
       kullanır. "Çok kısa" eşiği duruma göre değişmekle birlikte, genellikle,
       hata iletileriniz 512 bayttan büyük olduğu takdirde MSIE kendi hata
       iletileri yerine sunucunun ürettiği hata iletilerini gösterecektir. Bu
       konuda daha fazla bilgiyi <a
       href="http://support.microsoft.com/default.aspx?scid=kb;tr-tr;Q294807"
       >Q294807</a> kodlu Microsoft Knowledge Base makalesinde
       bulabilirsiniz.</p>

     <p>Çoğu yerleşik hata iletisi özel iletilerle değiştirilebilse de bazı
       durumlarda <directive module="core">ErrorDocument</directive> ile ne
       belirtildiğine bakılmaksızın yerleşik hata iletileri kullanılır.
       Özellikle, bozuk bir istek saptandığında normal istek işleme hemen
       devre dışı bırakılır ve yerleşik hata iletisi döndürülür. Bu, hatalı
       istekler yaparak güvenlik sorunlarına yol açılmak istenmesi
       durumlarında gereklidir.</p>

     <p><module>mod_proxy</module> kullanıyorsanız,
       <directive module="mod_proxy">ProxyErrorOverride</directive> yönergesini
       etkin kılmak isteyebilirsiniz, böylece asıl sunucular adına özel hata
       iletileri üretebilirsiniz. <code>ProxyErrorOverride</code> etkin
       kılınmak istenmezse, Apache httpd vekalet edilen içerik için özel hata
       belgeleri üretmeyecektir.</p>
 </usage>

 <seealso><a href="../custom-error.html">Özel Hata Yanıtları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ErrorLog</name>
 <description>Sunucunun hata günlüğünü tutacağı yeri belirler.</description>
 <syntax> ErrorLog <var>dosya-yolu</var>|syslog[:<var>oluşum</var>]</syntax>
 <default>ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows ve OS/2)</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>ErrorLog</directive> yönergesi sunucunun saptadığı hataları
       kaydedeceği dosyanın ismini belirtmek için kullanılır.
       <var>dosya-yolu</var> ile göreli dosya yolu belirtildiği takdirde
       dizininin <directive  module="core">ServerRoot</directive> ile
       belirtilen sunucu kök dizinine göre belirtildiği varsayılır.</p>

     <highlight language="config">
 ErrorLog "/var/log/httpd/error_log"
     </highlight>

     <p><var>dosya-yolu</var> bir boru imi "<code>|</code>" ile başlatıldığı
       takdirde hata iletilerinin hata günlüğünü işleme sokacak komuta
       borulanacağı varsayılır.</p>

     <highlight language="config">
 ErrorLog "|/usr/local/bin/httpd_errors"
     </highlight>

     <p>Daha fazla bilgi için <a href="../logs.html#piped">borulu
        günlüklere</a> bakınız.</p>

     <p>Dosya adı yerine <code>syslog</code> kullanılırsa, sistem desteklediği
       takdirde günlük kaydı syslogd(8) üzerinden yürütülür. Öntanımlı olarak
       <code>local7</code> syslog oluşumu kullanılır. Bunu
       <code>syslog:<var>oluşum</var></code> sözdizimini kullanarak
       değiştirebilirsiniz. Buradaki <code><var>oluşum</var></code>
       syslog.conf(5) kılavuz sayfasında belirtilen oluşum isimlerinden biri
       olabilir. Oluşum aslında küreseldir ve sanal konaklardan bazılarında
       değiştirilmişse, belirtilen en son oluşum tüm sunucuyu
       etkileyecektir.</p>

     <highlight language="config">
 ErrorLog syslog:user
     </highlight>

     <p>Buna ek olarak, modüller kendi günlük kaydı oluşturucusunu sağlayabilir.
       Sözdizimi yukarıdaki örnekte kullanılan <code>syslog</code> sözdiziminin
       benzeridir.</p>

     <p>GÜVENLİK: Günlük dosyalarının saklandığı dizin, sunucuyu başlatan
       kullanıcı dışındakiler tarafından yazılabilir olduğu takdirde
       güvenliğinizin nasıl tehlikeye gireceği <a
       href="../misc/security_tips.html#serverroot">güvenlik ipuçları</a>
       belgesinde ayrıntılı olarak açıklanmıştır.</p>
     <note type="warning"><title>Ek Bilgi</title>
       <p>Unix-dışı platformlarda dosya yolunu girerken, platform ters bölü
         çizgilerini desteklese bile normal bölü çizgileri kullanmaya özen
         göstermelisiniz. Genel olarak, dosya yollarını belirtirken
         yapılandırma dosyası boyunca normal bölü çizgisi kullanmak her zaman
         daha iyidir.</p>
     </note>
 </usage>
 <seealso><directive module="core">LogLevel</directive></seealso>
 <seealso><a href="../logs.html">Apache HTTP Sunucusunun Günlük Dosyaları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ErrorLogFormat</name>
 <description>Hata günlüğü girdileri için biçem belirtimi</description>
 <syntax> ErrorLogFormat [connection|request] <var>biçem</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>ErrorLogFormat</directive> yönergesi, hata günlüğünde asıl
       hata iletisine ek olarak günlüklenecek ek bilgiyi belirtmek için
       kullanılabilir.</p>

     <highlight language="config">
 #Basit örnek
 ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"
     </highlight>

     <p>İlk değiştirge olarak <code>connection</code> veya <code>request</code>
       belirtilmesi ek biçemlerin belirtilebilmesini sağlar. Böylece, belli bir
       bağlantı ya da istek için ilk ileti günlüklendiğinde ek bilgininde
       günlüklenmesi sağlanır. Bu ek bilgi sadece bağlantı/istek başına bir
       kere günlüklenir. herhangi bir günlük iletisine sebep olmadan işlenmişse
       ek bilgi de günlüklenmez.</p>

     <p>Bu, bazı biçem dizgesi öğeleri çıktı üretmediğinde olur. Örneğin,
       <code>Referer</code> başlığı sadece günlük iletisi bir istekle
       ilişkilendirilmişse mevcuttur ve hata iletisi <code>Referer</code>
       başlığı istemcide okunduğu anda oluşur. Eğer bir çıktı üretilmezse,
       öntanımlı davranış önceki boşluk karakterinden sonraki boşluk
       karakterine kadar herşeyi silmektir. Yani, günlük satırı örtük olarak
       boşluklarla ayrılmış alanlara bölünür. Bir biçem dizgesi öğesi çıktı
       üretmezse alanın tamamı çıktılanmaz. Örneğin, <code>[%t] [%l] [%a]
       %M&nbsp;</code> günlük biçeminde uzak adres <code>%a</code>
       kullanılamazsa sarmalayıcı köşeli ayraçlar da günlüklenmeyecektir.
       Boşluk karakterleri ters bölülerle öncelenerek bir alanı sınırlaması
       önlenebilir. '%&nbsp;' (yüzde boşluk) çifti sıfır genişlikte bir alan
       ayracı olup herhangi bir çıktı üretmez.</p>

     <p>Yukarıdaki davranış, biçem dizgesi öğesine değiştirciler eklenerek
       değiştirilebilir.  <code>-</code> (tire) değiştircisi ilgili öğe bir
       çıktı üretmediğinde tire iminin günlüklenmesine sebep olur.
       Bağlantı/istek başına bir kere biçemlerinde <code>+</code> (artı)
       değiştircisini de kullanmak mümkündür.Artı değiştiricili bir öğe
       herhangi bir çıktı üretmezse satırın tamamı günlüklenmez.</p>

     <p>Bir biçem öğesine günlük önem derecesi atamak için değiştirici
       olarak bir sayı kullanılabilir. Bu öğenin günlüklenebilmesi için günlük
       iletisinin önem derecesinin belirtilen günlük önem derecesinden
       daha yüksek olmaması gerekir. Sayı 1'den (alarm) 4'e (uyarı) ve 7'den
       (hata ayıklama) 15'e (trace8) kadar olabilir.</p>

     <p>Örneğin, <code>Referer</code> istek başlığını günlükleyen
       <code>%{Referer}i</code> dizgeciğine değiştirciler eklendiğinde neler
       olduğunu burada görebilirsiniz:</p>

     <table border="1" style="zebra">
     <columnspec><column width=".3"/><column width=".7"/></columnspec>

     <tr><th>Değiştirlen Dizgecik</th><th>Anlamı</th></tr>

     <tr>
     <td><code>%-{Referer}i</code></td>
     <td><code>Referer</code> atanmamışsa bir <code>-</code> günüklenir.</td>
     </tr>

     <tr>
     <td><code>%+{Referer}i</code></td>
     <td><code>Referer</code> atanmamışsa satırın tamamı çıktılanmaz.</td>
     </tr>

     <tr>
     <td><code>%4{Referer}i</code></td>
     <td>Sadece hata iletisinin önemi 4'ten yüksek olduğu durumda
       <code>Referer</code> günlüklenir.</td>
     </tr>

     </table>

     <p>Bazı biçem dizfesi öğeleri ayraç içine alınmış ek değiştirgeler kabul
       eder.</p>

     <table border="1" style="zebra">
     <columnspec><column width=".2"/><column width=".8"/></columnspec>

     <tr><th>Biçem&nbsp;Dizgesi</th> <th>Açıklama</th></tr>

     <tr><td><code>%%</code></td>
         <td>Yüzde imi</td></tr>

     <tr><td><code>%a</code></td>
         <td>İstekteki istemci IP adresi ve portu</td></tr>

     <tr><td><code>%{c}a</code></td>
         <td>Bağlantının emsal IP adresi and portu
           (<module>mod_remoteip</module> modülüne bakın)</td></tr>

     <tr><td><code>%A</code></td>
         <td>Yerel IP adresi ve portu</td></tr>

     <tr><td><code>%{<em>isim</em>}e</code></td>
         <td>İstek ortam değişkeni <em>isim</em></td></tr>

     <tr><td><code>%E</code></td>
         <td>APR/OS hata durum kodu ve iletisi</td></tr>

     <tr><td><code>%F</code></td>
         <td>Günlük çağrısının kaynak dosya ismi ve satır numarası</td></tr>

     <tr><td><code>%{<em>isim</em>}i</code></td>
         <td>İstek başlığı <em>isim</em></td></tr>

     <tr><td><code>%k</code></td>
         <td>Bağlantıdaki keep-alive isteklerinin sayısı</td></tr>

     <tr><td><code>%l</code></td>
         <td>İletinin günlük seviyesi</td></tr>

     <tr><td><code>%L</code></td>
         <td>İsteğin günlük kimliği</td></tr>

     <tr><td><code>%{c}L</code></td>
         <td>Bağlantının günlük kimliği</td></tr>

     <tr><td><code>%{C}L</code></td>
         <td>Bağlantı etki alanında kullanılmışsa bağlantının günlük kimliği,
           aksi takdirde boş</td></tr>

     <tr><td><code>%m</code></td>
         <td>İletiyi günlükleyen modülün ismi</td></tr>

     <tr><td><code>%M</code></td>
         <td>Asıl günlük iletisi</td></tr>

     <tr><td><code>%{<em>isim</em>}n</code></td>
         <td>istek notu <em>isim</em></td></tr>

     <tr><td><code>%P</code></td>
         <td>Geçerli sürecin süreç kimliği (PID'i)</td></tr>

     <tr><td><code>%T</code></td>
         <td>Geçerli evrenin evre kimliği</td></tr>

     <tr><td><code>%{g}T</code></td>
         <td>Geçerli evrenin eşsiz sistem evre kimliği (örn, <code>top</code>
           tarafınan gösterilenle aynı kimlik: şimdilik sadece Linux'a
           özgü)</td></tr>

     <tr><td><code>%t</code></td>
         <td>geçerli zaman</td></tr>

     <tr><td><code>%{u}t</code></td>
         <td>Mikro saniyeler dahil geçerli zaman</td></tr>

     <tr><td><code>%{cu}t</code></td>
         <td>ISO 8601 biçemiyle uyumlu mikro saniyeleri de içeren geçerli
           zaman</td></tr>

     <tr><td><code>%v</code></td>
         <td>Geçerli sunucunun kurallı <directive
         module="core">ServerName</directive></td></tr>

     <tr><td><code>%V</code></td>
         <td><directive module="core" >UseCanonicalName</directive> ayarına
           uygun olarak isteği sunan sunucunun sunucu ismi</td></tr>

     <tr><td><code>\&nbsp;</code> (tersbölü boşluk)</td>
         <td>Alan ayracı olmayan boşluk</td></tr>

     <tr><td><code>%&nbsp;</code> (yüzde boşluk)</td>
         <td>Alan ayracı (çıktısız)</td></tr>
     </table>

     <p>The log ID format <code>%L</code> günlük kimliği biçemi bağlantı veya
       istek için eşsiz bir kimlik üretir. Bu, bağlantı üzerinden gelen istek
       durumunda günlük satırlarının ait olduğu bağlantı veya isteği
       bağdaştırmak için kullanılabilir. <code>%L</code> biçem dizgesi ayrıca
       <module>mod_log_config</module> modülünde erişim günlüğü iletilerini
       hata günlüğü iletileriyle ilişklendirmek için de kullanılabilmektedir.
       <module>mod_unique_id</module> modülü yüklüyse onun eşsiz kimliği
       istekler için günlük kimliği olarak kullanılacaktır.</p>

     <highlight language="config">
 #Örnek (Evreli MPM'ler için öntanımlı biçim)
 ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a] %M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"
     </highlight>

     <p>Bunun hata iletilerindeki sonuçları şöyle olabilir:</p>

     <example>
     [Thu May 12 08:28:57.652118 2011] [core:error] [pid 8777:tid 4326490112] [client ::1:58619] File does not exist: /usr/local/apache2/htdocs/favicon.ico
     </example>

     <p>Dikkat edin, yukarıda açıklandığı gibi, bazı alanlar
       tanımlanmadıklarından tamamen yoksayılır.</p>

     <highlight language="config">
 #Örnek (2.2.x biçimine benzer)
 ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a] %M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"
     </highlight>

     <highlight language="config">
 #İstek/bağlantı günlük kimlikli gelişkin bir örnek
 ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"
 ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"
 ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"
 ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"
 ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"
     </highlight>

 </usage>
 <seealso><directive module="core">ErrorLog</directive></seealso>
 <seealso><directive module="core">LogLevel</directive></seealso>
 <seealso><a href="../logs.html">Apache HTTP Sunucusu Günlük Dosyaları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ExtendedStatus</name>
 <description>Her istekte ek durum bilgisinin izini sürer</description>
 <syntax>ExtendedStatus On|Off</syntax>
 <default>ExtendedStatus Off[*]</default>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p>Bu yönerge, o an işlenmekte olan istek hakkında evre başına ek veriyi
       ve kullanım özetini izler; <module>mod_status</module> modülünü
       yapılandırarak bu değişkenleri çalışma anında görebilirsiniz. Diğer
       modüllerin bu sonuçlara bel bağlayabileceğini unutmayın.</p>

     <p>Bu ayarlar sunucunun tamamına uygulanır ve bir sanal konakta etkin
       başka bir sanal konakta etkisiz kılınamaz. Ek durum bilgisinin
       toplanması sunucuyu yavaşlatabilir. Ayrıca, bu ayarın nazikçe yeniden
       başlatma sırasında değiştirilemeyeceğine dikkat ediniz.</p>

     <note>
       <p>Diğer üçüncü parti modüller aynısını yaparken
         <module>mod_status</module> modülünün yüklenmesi <code>ExtendedStatus
         On</code> için öntanımlı davranışı değiştirecektir. Böyle modüller,
         tüm evrelerin durumu hakkında ayrıntılı bilgi toplanmasına bel bağlar.
         Öntanımlı değer sürüm 2.3.6 itibariyle <module>mod_status</module>
         tarafından değiştirilmiştir. Önceki sürümlerde öntanımlı değer daima
         <code>Off</code> idi.</p>
     </note>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>FileETag</name>
 <description>Duruk dosyalar için <code>ETag</code> HTTP yanıt başlığını oluşturmakta kullanılacak dosya özniteliklerini belirler.</description>
 <syntax>FileETag <var>bileşen</var> ...</syntax>
 <default>FileETag MTime Size</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>2.3.14 ve öncesinde öntanımlı değer
   "INode&nbsp;MTime&nbsp;Size" idi.</compatibility>

 <usage>
     <p><directive>FileETag</directive> yönergesi, belge bir duruk dosyaya
       dayandığı takdirde <code>ETag</code> (Entity Tag - öğe etiketi
       kısaltması) yanıt başlığı alanını oluşturmakta kullanılacak dosya
       özniteliklerini yapılandırır. (<code>ETag</code> değeri, ağ band
       genişliğinden kazanmak için arabellek yönetiminde kullanılır.)
       <directive>FileETag</directive>yönergesi ne kullanılması gerektiğini
       belirleyebilmenizi sağlar. Değer olarak belirtilebilecek anahtar
       sözcükler şunlardır:</p>

     <dl>
      <dt><strong>INode</strong></dt>
      <dd>Dosyanın düğüm numarası hesaba katılır.</dd>
      <dt><strong>MTime</strong></dt>
      <dd>Dosyanın son değişiklik tarih ve saati dahil edilir.</dd>
      <dt><strong>Size</strong></dt>
      <dd>Dosyanın bayt cinsinden uzunluğu dahil edilir.</dd>
      <dt><strong>All</strong></dt>
      <dd>Olası tüm alanlar kullanılır. Bu şuna eşdeğerdir:
          <highlight language="config">
 FileETag INode MTime Size
          </highlight></dd>
      <dt><strong>None</strong></dt>
      <dd>Bir belge dosyasıyla sunulsa bile yanıta hiçbir <code>ETag</code>
       alanı dahil edilmez.</dd>
     </dl>

     <p>Öntanımlı ayarları miras alıp bunların kapsamını genişletmek/daraltmak
       için <code>INode</code>, <code>MTime</code> ve <code>Size</code>
       anahtar sözcüklerinin önüne <code>+</code> veya <code>-</code> imi
       konabilir. Bu imlerin bulunmadığı bir anahtar sözcüğün varlığı halinde
       hiçbir değer miras alınmaz.</p>

     <p>Eğer bir dizinin yapılandırması
       <code>FileETag&nbsp;INode&nbsp;MTime&nbsp;Size</code> ve alt dizini
       <code>FileETag&nbsp;-INode</code> içeriyorsa bu alt dizinin (ve bir
       geçersizleştirme olmadığı takdirde onun alt dizinlerinin) ayarları
       <code>FileETag&nbsp;MTime&nbsp;Size</code> yapılandırmasına eşdeğer
       olacaktır.</p>
     <note type="warning"><title>Uyarı</title>
       WebDAV’ın etkin olduğu yerlerde veya dizinlerde saklama alanı sağlayıcı
       olarak <module>mod_dav_fs</module> kullanılıyorsa öntanımlı ayarları
       değiştirmeyiniz. <module>mod_dav_fs</module>, koşullu isteklerde
       <code>ETag</code> karşılaştırmaları yapabilmek için
       <code>MTime&nbsp;Size</code> yapılandırmasını kullanır. Eğer
       <code>ETag</code> ayarı <directive>FileETag</directive> yönergesi
       kullanılarak değiştirilirse koşullu istekler gerektiği gibi yerine
       getirilemez.
     </note>
     <note><title>Sunucu Taraflı İçerik</title>
       Gömülü SSI yönergeleri ile bir duruk dosyanın <code>FileETag</code>,
       <code>MTime</code> ve <code>Size</code> değerleri değişmeksizin yanıt
       öğesi değişebileceğinden <module>mod_include</module> tarafından
       çözümlenen yanıtlar için bir <code>ETag</code> üretilmez.
     </note>
 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>Files</name>
 <description>Dosya isimleriyle eşleşme halinde uygulanacak yönergeleri
   içerir.</description>
 <syntax>&lt;Files <var>dosya-adı</var>&gt; ... &lt;/Files&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive type="section">Files</directive> yönergesi, içerdiği
       yönergelerin etki alanını dosya isimlerine göre sınırlandırır.
       <directive module="core" type="section">Directory</directive> ve
       <directive module="core" type="section">Location</directive> bölümleri
       ile karşılaştırılabilir. Bir <code>&lt;/Files&gt;</code> yönergesi ile
       sonlandırılması gerekir. Bu bölüm içinde belirtilen yönergeler,
       <directive type="section">Files</directive> yönergesinde belirtilen
       <var>dosya-adı</var>’nın son bileşeniyle (dizinler atıldıktan sonda
       kalan dosya ismi) eşleşen nesnelere uygulanır. <directive
       type="section">Files</directive> bölümleri yapılandırma dosyasında,
       <directive module="core" type="section">Directory</directive> bölümleri
       ve <code>.htaccess</code> dosyaları okunduktan sonra fakat <directive
       type="section" module="core">Location</directive> yönergelerinden önce
       göründükleri sıraya göre işleme sokulurlar. <directive
       type="section">Files</directive> bölümlerinin <directive type="section"
       module="core">Directory</directive> bölümlerinin içinde uygulama
       alanını sınırlamak amacıyla kullanılabileceğine dikkat ediniz.</p>

     <p><var>dosya-adı</var> argümanının bir dosya ismi veya bir dosya ismi
       kalıbı içermesi gerekir. Bir dosya ismi kalıbındaki her <code>?</code>
       imi bir karakterle eşleştirilirken <code>*</code> imi karakter dizileri
       ile eşleştirilir.</p>

     <highlight language="config">
 &lt;Files "zat.html"&gt;
     # zat.html dosyasına uygulanacakları buraya koy
 &lt;/Files&gt;

 &lt;Files "?at.*"&gt;
     # Buradakiler hat.html, kat.html, tat.html ve benzerlerine uygulanır.
 &lt;/Files&gt;
     </highlight>

     <p><code>~</code> imine ek olarak <glossary
       ref="regex">düzenli ifadeler</glossary> de kullanılabilir. Örneğin</p>

     <highlight language="config">
 &lt;Files ~ "\.(gif|jpe?g|png)$"&gt;
     #...
 &lt;/Files&gt;
     </highlight>

     <p>satırı en bilinen resim dosyası biçimleriyle eşleşecektir. Bunun
       yerine <directive module="core" type="section">FilesMatch</directive>
       yönergesi de tercih edilebilirdi.</p>

     <p><directive type="section" module="core">Directory</directive> ve
       <directive type="section" module="core">Location</directive>
       bölümlerinin aksine, <directive type="section">Files</directive>
       bölümleri <code>.htaccess</code> dosyaları içinde kullanılabilir. Bu
       sayede kullanıcıların kendi dosyalarına erişimi dosya seviyesinde
       denetlemelerine imkan sağlanmış olur.</p>

 </usage>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>FilesMatch</name>
 <description>Düzenli ifadelerin dosya isimleriyle eşleşmesi halinde
   uygulanacak yönergeleri içerir.</description>
 <syntax>&lt;FilesMatch <var>düzifd</var>&gt; ... &lt;/FilesMatch&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive type="section">FilesMatch</directive> yönergesi, içerdiği
       yönergelerin etki alanını <directive module="core"
       type="section">Files</directive> yönergesinin yaptığı gibi dosya
       isimlerine göre sınırlandırır. Ancak, argüman olarak bir <glossary
       ref="regex">düzenli ifade</glossary> kabul eder. Örneğin</p>

     <highlight language="config">
 &lt;FilesMatch "\.(gif|jpe?g|png)$"&gt;
     # ...
 &lt;/FilesMatch&gt;
     </highlight>

     <p>satırı en bilinen resim dosyası biçimleriyle eşleşecektir.</p>

     <note>Düzenli ifadenin başlangıcındaki bir <code>.+</code>
       <code>.png</code>veya <code>.gif</code> dosyalarının, örnek olarak,
       eşleşmemesini garanti eder.</note>

     <p>2.4.8 itibariyle, isimli gruplar ve geriye başvurular elde edilmekte
       olup ilgili isim büyük harfe çevrildikren sonra "MATCH_" ile
       öncelendikten sonra ortama yazılmaktadır. Böylece yol elemanlarına
       <module>mod_rewrite</module> gibi modüllerden veya <a
       href="../expr.html">düzenli ifadelerden</a> başvurmak mümkün
       kılınmıştır. Karışıklığı önlemek için, numaralı (isimsiz) geriye
       başvurular yoksayılmaktadır. Bunların yerine isimli geriye başvurular
       kullanılmalıdır.</p>

 <highlight language="config">
 &lt;FilesMatch "^(?&lt;sitename&gt;[^/]+)"&gt;
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 &lt;/FilesMatch&gt;
 </highlight>
 </usage>

 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ForceType</name>
 <description>Bütün dosyaların belirtilen ortam türüyle sunulmasına
   sebep olur.</description>
 <syntax>ForceType <var>ortam-türü</var>|None</syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>Apache httpd 2.0’da core modülüne taşındı.</compatibility>

 <usage>
     <p>Bu yönerge, bir <code>.htaccess</code> dosyası veya bir
       <directive type="section" module="core">Directory</directive>,
       <directive type="section" module="core">Location</directive> veya
       <directive type="section" module="core">Files</directive> bölümüne
       yerleştirildiği zaman, eşleşen tüm dosyaların <var>ortam-türü</var> ile
       belirtilen içerik türüyle sunulmasına sebep olur. Örneğin, altında
       sadece GIF dosyaları bulunan bir dizininiz varsa ve bunlara tek tek
       <code>.gif</code> uzantısı belirtmek istemiyorsanız şu yapılandırmayı
       kullanabilirsiniz:</p>

     <highlight language="config">
 ForceType image/gif
     </highlight>

     <p>Bu yönerge, <directive module="mod_mime">AddType</directive> yönergesi
       üzerinden ve <code>mime.types</code> dosyasında örtük olarak
       tanımlanmış ortam türü/dosya uzantısı ilişkilerini geçersiz kılar.</p>

     <p>Ayrıca, daha genel <directive>ForceType</directive> ayarlarını da
       <code>None</code> değeriyle geçersiz kılabilirsiniz:</p>

     <highlight language="config">
 # tüm dosyaların image/gif olarak sunulması için:
 &lt;Location "/images"&gt;
   ForceType image/gif
 &lt;/Location&gt;

 # normal MIME-türüne geri dönmek için:
 &lt;Location "/images/mixed"&gt;
   ForceType None
 &lt;/Location&gt;
     </highlight>

     <p>Bu yönerge, öncelikle dosya sisteminden sunulan duruk dosyalar için
       üretilen içerik türlerini geçersiz kılar. Duruk dosyaların haricindeki
       özkaynaklar için yanıt üretecinin genelde bir <code>Content-Type</code>
       belirttiği durumda bu yönerge etkisizdir.</p>

     <note><title>Ek Bilgi</title>
     <p><directive module="core" >SetHandler</directive> veya
       <directive module="mod_mime">AddHandler</directive> gibi örtük yönergeler
       geçerli isteğe uygulanmadığı takdirde, normalde bu yönergeler tarafından
       belirlenen dahili eylemcinin ismi <directive>ForceType</directive>
       yönergesi tarafından belirtilen içerik türü ile eşleşecek şekilde
       belirlenir. Bu, bazı üçüncü parti modüller (mod_php gibi) tarafından
       kullanılan tarihi bir uygulama olup, bu modüller istekle eşleşecek
       modüllerin sorumluluğu almasını sağlamak için "sihirli" içerik türleri
       kullanabilir. Bu tür "sihirli" içerik türlerini kullanan
       yapılandırmalarda <directive module="core" >SetHandler</directive> veya
       <directive module="mod_mime">AddHandler</directive> kullanımından
       kaçınılmalıdır. </p>
     </note>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>GprofDir</name>
 <description>gmon.out ayrıntılı inceleme verisinin yazılacağı dizin</description>
 <syntax>GprofDir <var>/tmp/gprof/</var>|<var>/tmp/gprof/</var>%</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p>Sunucu gprof ayrıntılı inceleme desteği ile derlenmişse,
       <directive>GprofDir</directive> yönergesi <code>gmon.out</code>
       dosyalarının süreç çıktığında belirtilen dizine yazılmasını sağlar. Eğer
       değiştirge bir yüzde simgesi ('%') ile bitiyorsa her süreç kimliği için
       alt dizinler oluşturulur.</p>

     <p>Bu yönerge şimdilik sadece <module>prefork</module> MPM'i ile
       çalışmaktadır.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>HostnameLookups</name>
 <description>İstemci IP adresleri üzerinde DNS sorgularını etkin kılar.
 </description>
 <syntax>HostnameLookups On|Off|Double</syntax>
 <default>HostnameLookups Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context></contextlist>

 <usage>
     <p>Bu yönerge oturum açabilecek konak isimlerini tespit edebilmek için
       DNS sorgularını etkin kılar (ve sonuç <code>REMOTE_HOST</code>’ta
       belirtilerek CGI/SSI’lere aktarılır). <code>Double</code> değeri
       sorgunun çift yönlü yapılacağını belirtir. Yani, bir tersine sorgunun
       ardından bir normal sorgu yapılır. Normal sorguda elde edilen IP
       adreslerinden birinin istek yapan IP adresi ile eşleşmesi gerekir.
       ("tcpwrappers" terminolojisinde buna <code>PARANOID</code> adı
       verilir.)</p>

     <p>Konak ismine göre erişimi denetlemek için
       <module>mod_authz_host</module> kullanıldığında, nasıl bir ayar
       yapıldığına bakılmaksızın, çift yönlü sorgulama yapılır. Bu güvenlik
       için gereklidir. Bunun dışında açıkça <code>HostnameLookups
       Double</code> belirtilmedikçe genellikle çift yönlü sorgulama yapılmaz.
       Örneğin, sadece  <code>HostnameLookups On</code> belirtilmiş ve konak
       ismi kısıtlamalarıyla korunmuş bir nesne için bir istek yapılmışsa çift
       yönlü sorgunun başarısına bakılmaksızın CGI’lere
       <code>REMOTE_HOST</code> olarak tek yönlü sorgu sonucu aktarılır.</p>

     <p>Gerçekte ters yönlü sorguya gerek duyulmayan sitelerde ağ trafiğini
       yormamak için <code>Off</code>, öntanımlı değerdir. Ayrıca, son
       kullanıcıların DNS sorguları nedeniyle gereksiz yere bir beklemeye
       maruz kalmaması için de bu daha iyidir. Yükü zaten ağır olan sitelerde,
       DNS sorgularının görece uzun zaman alması nedeniyle bu yönergenin
       değeri <code>Off</code> olarak bırakılmalıdır. Öntanımlı olarak kurulum
       dizininizin <code>bin</code> alt dizinine kurulan
       <program>logresolve</program> uygulaması kullanılarak oturum açan IP
       adresleri için isim sorguları çevrim dışıyken yapılabilir.</p>

     <p>Son olarak, <a href="mod_authz_host.html#reqhost">konak ismine dayalı
       Require yönergeleri</a>ne sahipseniz konak ismi araması
       <code>HostnameLookups</code> ayarına bakılmaksızın
       gerçekleştirilecektir.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>If</name>
 <description>Çalışma anında bir koşul bir istek tarafından yerine getirildiği
 takdirde uygulanacak yönergeleri barındırır.</description>
 <syntax>&lt;If <var>ifade</var>&gt; ... &lt;/If&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive type="section">If</directive> yönergesi bir ifadeyi çalışma
       anında değerlendirir ve ifadenin sonucu doğru olduğu takdirde içerdiği
       yönergeleri uygular. Örnek:</p>

     <highlight language="config">
 &lt;If "-z req('Host')"&gt;
     </highlight>

     <p>Bir <var>Host:</var> başlığı içermeyen HTTP/1.0 istekleriyle
       eşleşir. İfadeler, dizge karşılaştırması (<code>==</code>,
       <code>!=</code>, <code>&lt;</code>, ...), tamsayı karşılaştırması
       (<code>-eq</code>, <code>-ne</code>, ...) ve diğerleri (<code>-n</code>,
       <code>-z</code>, <code>-f</code>, ...) için kabuktakilere benzer çeşitli
       işleçler içerebilir. Ayrıca, düzenli ifadeleri,</p>

     <highlight language="config">
 &lt;If "%{QUERY_STRING} =~ /(delete|commit)=.*?elem/"&gt;
     </highlight>

     <p>kabuk tarzı kalıp eşleştirme ve birçok başka işlemi kullanmak da
       mümkündür. Bu işlemler istek başlıklarında (<code>req</code>), ortam
       değişkenlerinde (<code>env</code>) ve çok sayıda başka niteliklerin
       üstünde yapılabilir. <a href="../expr.html">Apache HTTP Sunucusundaki
       İfadeler</a> belgesinde daha ayrıntılı bilgi bulabilirsiniz.</p>

     <p>Bu yapılandırma bölümünün içinde sadece
       <a href="directive-dict.html#Context">dizin bağlamını</a> destekleyen
       yönergeler kullanılabilir.</p>

     <note type="warning">
     &lt;If&gt; sonrasında atanan <code>CONTENT_TYPE</code> gibi belli
     değişkenler ve diğer yanıt başlıkları zaten yorumlanmış olacaklarından bu
     yönerge için kullanılabilir olmayacaktır.
     </note>
 </usage>

 <seealso><a href="../expr.html">Apache HTTP Sunucusundaki
   İfadeler</a> belgesinde daha ayrıntılı bilgi ve örnek
   bulabilirsiniz.</seealso>
 <seealso><directive type="section" module="core">ElseIf</directive></seealso>
 <seealso><directive type="section" module="core">Else</directive></seealso>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.
   <directive type="section">If</directive>,
   <directive type="section">ElseIf</directive> ve
   <directive type="section">Else</directive> son olarak uygulanır.</seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>IfDefine</name>
 <description>Başlatma sırasında bir doğruluk sınamasından sonra işleme
 sokulacak yönergeleri sarmalar.</description>
 <syntax>&lt;IfDefine [!]<var>parametre-adı</var>&gt; ...
     &lt;/IfDefine&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><code>&lt;IfDefine <var>sınama</var>&gt;...&lt;/IfDefine&gt;
       </code> bölümü koşullu olarak işleme sokulacak yönergeleri içerir.
       Bir <directive type="section">IfDefine</directive> bölümü içindeki
       yönergeler sadece <var>sınama</var> doğru sonuç verirse işleme sokulur.
       Aksi takdirde, bölüm içinde kalan her şey yok sayılır.</p>

     <p><directive type="section">IfDefine</directive> bölüm yönergesinde
       <var>sınama</var> için belirtilebilecek iki biçim vardır:</p>

     <ul>
       <li><var>parametre-adı</var></li>

       <li><code>!</code><var>parametre-adı</var></li>
     </ul>

     <p>Birinci durumda bölüm içinde kalan yönergeler sadece
       <var>parametre-adı</var> ile belirtilen parametre tanımlı ise işleme
       sokulur. İkinci durumda ise tersi yapılır, yani sadece
       <var>parametre-adı</var> ile belirtilen parametre tanımlı
       <strong>değil</strong> ise yönergeler işleme sokulur.</p>

     <p><var>parametre-adı</var> argümanı sunucu başlatılırken
       <program>httpd</program> komut satırında
       <code>-D<var>parametre</var></code> ile
       veya <directive module="core">Define</directive> yönergesi ile
       belirtilerek tanımlı hale getirilebilir.</p>

     <p><directive type="section">IfDefine</directive> bölümleri iç içe
       olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.
       Örnek:</p>

     <example>httpd -DReverseProxy -DUseCache -DMemCache ...</example>
     <highlight language="config">
 &lt;IfDefine ReverseProxy&gt;
   LoadModule proxy_module   modules/mod_proxy.so
   LoadModule proxy_http_module   modules/mod_proxy_http.so
   &lt;IfDefine UseCache&gt;
     LoadModule cache_module   modules/mod_cache.so
     &lt;IfDefine MemCache&gt;
       LoadModule mem_cache_module   modules/mod_mem_cache.so
     &lt;/IfDefine&gt;
     &lt;IfDefine !MemCache&gt;
       LoadModule cache_disk_module   modules/mod_cache_disk.so
     &lt;/IfDefine&gt;
   &lt;/IfDefine&gt;
 &lt;/IfDefine&gt;
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>IfModule</name>
 <description>Belli bir modülün varlığına veya yokluğuna göre işleme sokulacak
 yönergeleri sarmalar.</description>
 <syntax>&lt;IfModule [!]<var>modül-dosyası</var>|<var>modül-betimleyici</var>&gt; ...
     &lt;/IfModule&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>
 <compatibility>Modül betimleyiciler 2.1 sürümünde ve sonrası için geçerlidir.</compatibility>

 <usage>
     <p><code>&lt;IfModule <var>sınama</var>&gt;...&lt;/IfModule&gt;</code>
       bölümü belli bir modülün varlığına veya yokluğuna göre işleme sokulacak
       yönergeleri içerir. Bir <directive type="section">IfModule</directive>
       bölümü içindeki yönergeler sadece <var>sınama</var> doğru sonuç verirse
       işleme sokulur. Aksi takdirde, bölüm içinde kalan her şey yok sayılır.</p>

     <p><directive type="section">IfModule</directive> bölüm yönergesinde
       <var>sınama</var> için belirtilebilecek iki biçim vardır:</p>

     <ul>
       <li><var>modül</var></li>

       <li>!<var>modül</var></li>
     </ul>

     <p>Birinci durumda bölüm içinde kalan yönergeler sadece <var>modül</var>
       ile belirtilen modül Apache httpd içine dahil edilmişse veya
       <directive module="mod_so">LoadModule</directive> yönergesi ile devingen
       olarak yüklenmişse işleme sokulur. İkinci durumda ise tersi yapılır, yani
       sadece <var>modül</var> içerilmiş <strong>değil</strong> ise yönergeler
       işleme sokulur.</p>

     <p><var>modül</var> argümanında bir modül betimleyici veya modülün derleme
       sırasındaki dosya adı belirtilebilir. Örneğin, <code>rewrite_module</code>
       bir betimleyici, <code>mod_rewrite.c</code> ise bir dosya ismidir. Eğer
       modül çok sayıda kaynak dosyasından oluşuyorsa
       <code>STANDARD20_MODULE_STUFF</code> dizgesini içeren dosyanın ismi
       kullanılır.</p>

     <p><directive type="section">IfModule</directive> bölümleri iç içe
       olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.</p>

     <note>Bu bölümü sadece yapılandırma dosyanızın belli modüllerin varlığına
       veya yokluğuna bağlı olarak çalışması gerektiği durumlarda
       kullanmalısınız. Normal işlemlerde yönergelerin <directive
       type="section">IfModule</directive> bölümlerine yerleştirilmeleri
       gerekmez.</note>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>Include</name>
 <description>Sunucu yapılandırma dosyalarının başka dosyaları içermesini sağlar.
 </description>
 <syntax>Include <var>dosya-yolu</var>|<var>dizin-yolu</var>|<var>joker</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context>
 </contextlist>
 <compatibility>Dizin kalıbıyla eşleşme ise 2.3.6 ve sonrasında mevcuttur.</compatibility>

 <usage>
     <p>Bu yönerge sunucu yapılandırma dosyalarının başka dosyaları içermesini
       mümkün kılar.</p>

     <p>Çok sayıda dosyayı bir kerede alfabetik sırada içermek için yolun dosya
       ismi ve dizin parçalarında kabuk tarzı (<code>fnmatch()</code>) dosya
       ismi kalıp karakterleri kullanılabilir. Ayrıca, eğer
       <directive>Include</directive> yönergesi bir dosya değil de bir dizin
       gösteriyorsa Apache httpd bu dizindeki ve alt dizinlerindeki bütün
       dosyaları okuyacaktır. Bunula birlikte, dizinin bir bütün olarak
       okutulması önerilmez, çünkü dizinde <program>httpd</program> programının
       çökmesine sebep olabilecek geçici dosyalar unutulabilir. Bunun yerine,
       belli bir şablona uyan dosyaları seçebilmek için, örneğin *.conf gibi
       dosya kalıplarının kullanılmasını öneriyoruz.</p>

     <p><directive module="core">Include</directive> yönergesi, bir dosya
       kalıbı ifadesi hiçbir dosyayla eşleşmezse <strong>bir hatayla
       başarısız</strong>  olacaktır. Eşleşmeyen dosya kalıbı ifadelerinin
       yoksayılması gerekiyorsa <directive module="core"
       >IncludeOptional</directive> yönergesi kullanılabilir.</p>

     <p>Dosya yolu mutlak bir dosya yolu olarak belirtilebileceği gibi
       <directive module="core">ServerRoot</directive> dizinine göreli olarak
       da belirtilebilir.</p>

     <p>Örnekler:</p>

     <highlight language="config">
 Include /usr/local/apache2/conf/ssl.conf
 Include /usr/local/apache2/conf/vhosts/*.conf
     </highlight>

     <p>Veya dizinler <directive module="core">ServerRoot</directive> dizinine
       göre belirtilebilir:</p>

     <highlight language="config">
 Include conf/ssl.conf
 Include conf/vhosts/*.conf
     </highlight>

      <p>Dosya kalıbı karakterleri yolun dizin ve dosya parçalarına
        yerleştirilebilir. <code>conf/vhosts</code> altında en azından bir
        <code>*.conf</code> içeren hiçbir alt dizin yoksa bu örnek başarısız
        olacaktır:</p>

     <highlight language="config">
 Include conf/vhosts/*/*.conf
     </highlight>

     <p>Bunun yerine, dizin ve dosyaların eksikliği durumunda aşağıdaki komut
       sadece yoksayılır:</p>

     <highlight language="config">
 IncludeOptional conf/vhosts/*/*.conf
     </highlight>

 </usage>
 <seealso><directive module="core">IncludeOptional</directive></seealso>
 <seealso><program>apachectl</program></seealso>
 </directivesynopsis>

  <directivesynopsis>
 <name>IncludeOptional</name>
 <description>Diğer yapılandırma dosyalarının sunucu yapılandırma dosyasına dahil edilmesini sağlar</description>
 <syntax>IncludeOptional <var>dosya-yolu</var>|<var>dizin-yolu</var>|<var>joker</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context>
 </contextlist>
 <compatibility>2.3.6 ve sonrasına kullanılabilmektedir.</compatibility>

 <usage>
     <p>Bu yönerge, diğer yapılandırma dosyalarının sunucu yapılandırma
       dosyasında içerilmesini sağlar. Çalışması <directive
       module="core">Include</directive> yönergesi ile bir istisna dışında
       aynıdır. Dosya kalıp karakterlerinin hiçbir dosya veya dizinle
       eşleşmemesi durumunda <directive module="core"
       >IncludeOptional</directive> yönergesi bir hataya sebep olmak yerine
       bunu sadece yoksayacaktır.</p>
 </usage>

 <seealso><directive module="core">Include</directive></seealso>
 <seealso><program>apachectl</program></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>KeepAlive</name>
 <description>HTTP kalıcı bağlantılarını etkin kılar</description>
 <syntax>KeepAlive On|Off</syntax>
 <default>KeepAlive On</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><code>Keep-Alive</code> yönergesi HTTP/1.0 protokolüne bir eklenti olup
       HTTP/1.1 protokolünün kalıcı bağlantı özelliği aynı TCP bağlantısı
       üzerinden çok sayıda isteğin gönderilmesini mümkün kılan uzun süreli HTTP
       oturumları açılmasını sağlar. Bunun, çok sayıda resim içeren HTML
       belgelerin yanıt zamanlarında bazı durumlarda %50’lik bir hızlanmayla
       sonuçlandığı gösterilmiştir. Kalıcı bağlantıları etkin kılmak için
       yönerge <code>KeepAlive On</code> şeklinde kullanılır.</p>

     <p>HTTP/1.0 istemcileri için kalıcı bağlantılar sadece bir istemci
       tarafından özellikle istendiği takdirde kullanılabilir. Ek olarak,
       HTTP/1.0 istemci kalıcı bağlantıları sadece içerik uzunluğu baştan
       bilindiği zaman kullanılabilir. Bu, CGI çıktısı, SSI sayfaları ve
       sunucunun ürettiği dizin listeleri gibi genellikle HTTP/1.0 istemcilere
       kalıcı bağlantılar kullanmayan devingen içeriklere uygulanır. HTTP/1.1
       istemciler için kalıcı bağlantılar aksi belirtilmedikçe öntanımlıdır.
       İstemci istediği takdirde, uzunluğu bilinmeyen içerik kalıcı bağlantılar
       üzerinden gönderilirken parçalı kodlama kullanılacaktır.</p>

     <p>Bir istemci kalıcı bağlantı kullandığı takdirde, bağlantı üzerinden kaç
       istek gönderilirse gönderilsin,
       <directive module="mpm_common">MaxConnectionsPerChild</directive>
       yönergesi bakımından tek bir istek olarak değerlendirilir.</p>
 </usage>

 <seealso><directive module="core">MaxKeepAliveRequests</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>KeepAliveTimeout</name>
 <description>Bir kalıcı bağlantıda sunucunun bir sonraki isteği bekleme süresi
 </description>
 <syntax>KeepAliveTimeout <var>sayı</var>[ms]</syntax>
 <default>KeepAliveTimeout 5</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p>Sunucunun kalıcı bir bağlantıyı kapatmadan önce bir sonraki isteği kaç
       saniye bekleyeceğini belirler. Ayrıca, ms soneki kullanılarak süreyi
       milisaniye olarak belirtmek de mümkündür. İstek alındıktan sonra
       <directive module="core">Timeout</directive> yönergesiyle belirtilen
       zaman aşımı değeri uygulanır.</p>

     <p><directive>KeepAliveTimeout</directive> için yüksek bir değer belirtmek
       ağır yüklü sunucularda başarım sorunlarına yol açar. Daha yüksek bir
       zaman aşımı, boştaki istemcilerin bulunduğu bağlantıları bekleyen daha
       fazla sunucu sürecini meşgul edecektir.</p>

     <p>İsme dayalı sanal konak için <directive>KeepAliveTimeout</directive>
       atanmamışsa, yerel IP adresi ve portu ile en iyi eşleşen ilk sanal
       konağın değeri kullanılır.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>Limit</name>
 <description>Erişimi sınırlanacak HTTP yöntemleri için erişim sınırlayıcıları
 sarmalar.</description>
 <syntax>&lt;Limit <var>yöntem</var> [<var>yöntem</var>] ... &gt; ...
     &lt;/Limit&gt;</syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>AuthConfig, Limit</override>

 <usage>
     <p>Erişim denetleyicileri normalde <strong>tüm</strong> erişim yöntemleri
       için etkindir ve olağan olanı da budur. <strong>Genel durum olarak,
       erişim denetim yönergeleri bir <directive
       type="section">Limit</directive> bölümüne
       yerleştirilmemelidir.</strong></p>

     <p><directive type="section">Limit</directive> bölümünün amacı, erişim
       denetleyicilerinin etkilerini belli HTTP yöntemleri için sınırlamaktır.
       <directive type="section">Limit</directive> bölümü içinde listelenen
       erişim sınırlamaları, kalan tüm diğer yöntemler için <strong>etkisiz
       olacaktır</strong>. Aşağıdaki örnekte, erişim sınırlaması
       <code>POST</code>, <code>PUT</code> ve <code>DELETE</code> yöntemleri
       için uygulanmakta, diğer tüm yöntemler korumasız bırakılmaktadır:</p>

     <highlight language="config">
 &lt;Limit POST PUT DELETE&gt;
   Require valid-user
 &lt;/Limit&gt;
     </highlight>

     <p>Birden fazla bölümde kullanılabilecek yöntem isimleri: <code>GET</code>,
       <code>POST</code>, <code>PUT</code>, <code>DELETE</code>,
       <code>CONNECT</code>, <code>OPTIONS</code>,
       <code>PATCH</code>, <code>PROPFIND</code>, <code>PROPPATCH</code>,
       <code>MKCOL</code>, <code>COPY</code>, <code>MOVE</code>,
       <code>LOCK</code> ve <code>UNLOCK</code>. <strong>Yöntem isimleri harf
       büyüklüğüne duyarlıdır.</strong> <code>GET</code> yöntemi sınırlanırsa
       <code>HEAD</code> istekleri de sınırlanmış olur. <code>TRACE</code>
       yöntemi sınırlanamaz (bkz, <directive module="core"
       >TraceEnable</directive>).</p>

     <note type="warning">Erişimi sınarlarken bir <directive
       type="section">Limit</directive> bölümü yerine daima bir <directive
       type="section" module="core">LimitExcept</directive> bölümünü tercih
       etmelisiniz, çünkü <directive type="section" module="core"
       >LimitExcept</directive> bölümü belirtilen yöntemler dışında kalanlara
       erişim koruması sağlar.</note>

     <p><directive type="section">Limit</directive> ve
     <directive type="section" module="core">LimitExcept</directive>
     yönergeleri iç içe olabilirler. Bu durumda, başarılı her
     <directive type="section">Limit</directive> veya <directive
     type="section" module="core">LimitExcept</directive> seviyesi, erişim
     denetimlerinin uygulanacağı yöntemlerle sınırlı kalmalıdır.</p>

     <note type="warning"><directive type="section">Limit</directive> veya
     <directive type="section">LimitExcept</directive> yönergelerini
     <directive module="mod_authz_core">Require</directive> yönergesi ile
     birlikte kullanılırken, ilk <directive module="mod_authz_core"
     >Require</directive> yönergesinin bir başka <directive
     module="mod_authz_core">Require</directive> yönergesinin varlığından
     bağımsız olarak isteği başarıyla yetkilendirdiğine dikkat ediniz.</note>

     <p>Örneğin, aşağıdaki yapılandırmayı ele alalım; tüm kullanıcılar
     <code>POST</code> istekleri için yetkilendirilecek ve tüm durumlarda
     <code>Require group editors</code> yönergesi yoksayılacaktır:</p>

     <highlight language="config">
 &lt;LimitExcept GET&gt;
   Require valid-user
 &lt;/LimitExcept&gt;
 &lt;Limit POST&gt;
   Require group editors
 &lt;/Limit&gt;
     </highlight>

 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>LimitExcept</name>
 <description>İsimleri belirtilenler dışında kalan HTTP yöntemleri için
 kullanılacak erişim sınırlayıcıları sarmalar.</description>
 <syntax>&lt;LimitExcept <var>yöntem</var> [<var>yöntem</var>] ... &gt; ...
     &lt;/LimitExcept&gt;</syntax>
 <contextlist><context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>AuthConfig, Limit</override>

 <usage>
     <p><directive type="section">LimitExcept</directive> ve
       <code>&lt;/LimitExcept&gt;</code> argüman olarak belirtilenler
       <strong>dışında</strong> kalan HTTP yöntemleri için kullanılacak erişim
       sınırlayıcıları gruplamakta kullanılır. Yani, <directive type="section"
       module="core">Limit</directive> bölümünün tersine, standart olsun olmasın
       bütün yöntemler için erişimi kısıtlamakta kullanılabilir. Daha ayrıntılı
       bilgi edinmek için <directive module="core" type="section"
       >Limit</directive> yönergesinin açıklamasına bakınız.</p>

     <p>Örnek:</p>

     <highlight language="config">
 &lt;LimitExcept POST GET&gt;
   Require valid-user
 &lt;/LimitExcept&gt;
     </highlight>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitInternalRecursion</name>
 <description>Dahili yönlendirmelerin ve istek içi isteklerin azami sayısını
 belirler.</description>
 <syntax>LimitInternalRecursion <var>sayı</var> [<var>sayı</var>]</syntax>
 <default>LimitInternalRecursion 10</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p>Örneğin, özgün istekleri dahili olarak bir CGI betiğine yönlendiren
       <directive module="mod_actions">Action</directive> yönergesi
       kullanıldığında bir dahili yönlendirme oluşur. İstek içi istekler ise
       bazı URI’ler için istek yapıldığında ne olacağını bulmak için Apache
       httpd’nin kullandığı bir mekanizmadır. Örneğin,
       <module>mod_dir</module>, <directive module="mod_dir"
       >DirectoryIndex</directive> yönergesinde listelenen dosyalara bakmak
       için istek içi istekler kullanır.</p>

     <p><directive>LimitInternalRecursion</directive> yönergesi sunucunun dahili
       yönlendirmeler ve istek içi isteklerin oluşturduğu döngülerden dolayı
       çökmemesini sağlar. Böyle döngüler genellikle yanlış yapılandırma sonucu
       ortaya çıkarlar.</p>

     <p>Yönerge her istek için değerlendirmeye alınacak iki farklı sınırlama
       için kullanılabilir. İlk <var>sayı</var> ardarda gelebilen dahili
       yönlendirmelerin azami sayısını, ikinci <var>sayı</var> ise istek içi
       isteklerin ne kadar iç içe olabileceğini belirler. Tek bir
       <var>sayı</var> belirtilirse iki sınırlama için de aynı değer
       kullanılır.</p>

     <highlight language="config">
 LimitInternalRecursion 5
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitRequestBody</name>
 <description>İstemci tarafından gönderilen HTTP istek gövdesinin toplam
 uzunluğunu sınırlar.</description>
 <syntax>LimitRequestBody <var>bayt-sayısı</var></syntax>
 <default>LimitRequestBody 0</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p>Bu yönerge, bir istek gövdesinde izin verilen bayt sayısını 0 (sınırsız
       anlamında) ile 2147483647 (2GB) arasında sınırlamak için kullanılır.
       Vekil isteklerinin snırlı uygulanabilirliği için aşağıdaki nota
       bakınız.</p>

     <p><directive>LimitRequestBody</directive> yönergesi kullanıcıya yönergenin
       kullanıldığı bağlam (sunucu, belli bir dizin, belli bir dosya, belli bir
       yer) dahilinde bir HTTP istek iletisi gövdesinin izin verilen uzunluğu
       için bir sınır belirleme imkanı verir. Eğer istemcinin isteği bu sınırı
       aşarsa sunucu isteği sunmak yerine bir hata iletisi döndürecektir. Normal
       bir istek ileti gövdesinin uzunluğu büyük oranda özkaynağın doğasına ve
       bu özkaynak üzerinde izin verilen yöntemlere bağlıdır. CGI betikleri
       genellikle ileti gövdesini form bilgisini almak için kullanır.
       <code>PUT</code> yöntemi gerçeklenimleri, en azından, sunucunun o
       özkaynak için kabul etmek isteyeceği herhangi bir gösterim kadar büyük
       bir değer gerektirecektir.</p>

     <p>Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu
       yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim
       imkanı sağlar.</p>

     <p>Eğer, örneğin, belli bir yere dosya yükleme izni verir ve buraya
       yüklenebilecek dosya boyutunu 100 kB ile sınırlamak isterseniz yönergeyi
       şöyle kullanabilirsiniz:</p>

     <highlight language="config">
 LimitRequestBody 102400
     </highlight>

     <note><p>Bu yönergenin vekil istekleri tarafından nasıl yorumlandığı
       <module>mod_proxy</module> belgesinde ayrıntılı olarak
       açıklanmıştır.</p>
     </note>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitRequestFields</name>
 <description>İstemciden kabul edilecek HTTP isteği başlık alanlarının sayısını
 sınırlar.</description>
 <syntax>LimitRequestFields <var>sayı</var></syntax>
 <default>LimitRequestFields 100</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>

 <usage>
     <p><var>sayı</var>, en küçük 0 (sınırsız anlamında), en büyük 32767
       olabilir. Öntanımlı değer bir derleme zamanı sabiti olan
       <code>DEFAULT_LIMIT_REQUEST_FIELDS</code> ile belirlenir (dağıtımla gelen
       değeri 100’dür).</p>

     <p><directive>LimitRequestFields</directive> yönergesi sunucu
       yöneticilerine bir HTTP isteğinde izin verilen istek başlık alanlarının
       sayısı üzerindeki sınırı değiştirebilme imkanı verir. Sunucu bu değerin,
       normal bir istemci isteğinin içerebileceği alan sayısından daha büyük
       olmasına ihtiyaç duyar. Bir istemci tarafından kullanılan istek başlık
       alanlarının sayısı nadiren 20’yi geçer, fakat bu farklı istemci
       gerçeklenimleri için değişiklik gösterir ve çoğunlukla kullanıcının
       tarayıcısını ayrıntılı içerik müzakeresini desteklemek için nasıl
       yapılandırdığıyla ilgilidir. İsteğe bağlı HTTP eklentileri çoğunlukla
       istek başlık alanları kullanılarak ifade edilir.</p>

     <p>Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu
       yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim
       imkanı sağlar. Eğer normal istemciler sunucudan istekte bulunurken çok
       fazla başlık alanı gönderildiğine dair bir hata iletisi alırlarsa bu
       değerin arttırılması gerekir.</p>

     <p>Örnek:</p>

     <highlight language="config">
 LimitRequestFields 50
     </highlight>

      <note type="warning"><title>Uyarı</title>
      <p>İsme dayalı sanal konaklar kullanıldığında, bu yönergenin değeri,
        yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal
        konaktan alınır.</p>.
      </note>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitRequestFieldSize</name>
 <description>İstemciden kabul edilecek HTTP isteği başlık uzunluğunu sınırlar.
 </description>
 <syntax>LimitRequestFieldSize <var>bayt-sayısı</var></syntax>
 <default>LimitRequestFieldSize 8190</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>

 <usage>
     <p>Bu yönerge, HTTP istek başlığında izin verilecek bayt sayısını
       belirler.</p>

     <p><directive>LimitRequestFieldSize</directive> yönergesi, sunucu
       yöneticilerine  HTTP istek başlık alanının azami uzunluğunu ayarlama
       imkanı verir. Sunucu bu değerin, normal bir istemci isteğinin
       içerebileceği herhangi bir başlık alanını tutabilecek kadar büyük
       olmasını gerektirir. Normal bir istek başlık alanı uzunluğu kullanıcının
       tarayıcısını ayrıntılı içerik müzakeresini desteklemek için nasıl
       yapılandırdığıyla ilgilidir. SPNEGO kimlik doğrulama başlıkları 12392
       baytlık olabilir.</p>

     <p>Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu
       yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim
       imkanı sağlar.</p>

     <p>Örnek:</p>

     <highlight language="config">
 LimitRequestFieldSize 4094
     </highlight>

     <note>Normal şartlar altında öntanımlı değer değiştirilmemelidir. Ayrıca,
       kaynak kodu değiştirip yeniden derlemeden bu değeri 8190'dan büyük
       yapamazsınız.</note>

     <note type="warning"><title>Uyarı</title>
     <p>İsme dayalı sanal konaklar kullanıldığında, bu yönergenin değeri,
        yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal
        konaktan alınır.</p>
     </note>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitRequestLine</name>
 <description>İstemciden kabul edilecek HTTP istek satırının uzunluğunu sınırlar.
 </description>
 <syntax>LimitRequestLine <var>bayt-sayısı</var></syntax>
 <default>LimitRequestLine 8190</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>

 <usage>
     <p>Bu yönerge, HTTP istek satırında izin verilecek bayt sayısını
       belirler.</p>

     <p><directive>LimitRequestLine</directive> yönergesi, sunucu yöneticilerine
       bir istemcinin HTTP istek satırının azami uzunluğunu ayarlama
       imkanı verir. İstek satırının içeriği HTTP yöntemi, URI ve protokol
       sürümünden oluştuğundan <directive>LimitRequestLine</directive>
       yönergesi, sunucudan bir istek için kullanılan istek adresinin uzunluğunu
       sınırlamış olur. Sunucu bu değerin, bir <code>GET</code> isteğinin sorgu
       kısmında aktarılabilen her bilgi dahil, özkaynak isimlerinden her birini
       tutabilecek kadar büyük olmasını gerektirir.</p>

     <p>Bu yönerge, bazı hizmet reddi (DoS) saldırılarından kaçınmak için sunucu
       yöneticilerine, anormal istemci istekleri üzerinde daha iyi denetim
       imkanı sağlar.</p>

     <p>Örnek:</p>

     <highlight language="config">
 LimitRequestLine 4094
     </highlight>

     <note>Normal şartlar altında öntanımlı değer değiştirilmemelidir.</note>

     <note type="warning"><title>Uyarı</title>
     <p>İsme dayalı sanal konaklar kullanıldığında, bu yönergenin değeri,
        yerel IP adresi ve port çifti için öntanımlı olan (listedeki ilk) sanal
        konaktan alınır.</p>
     </note>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>LimitXMLRequestBody</name>
 <description>Bir XML temelli istek gövdesinin uzunluğunu sınırlar.</description>
 <syntax>LimitXMLRequestBody <var>bayt-sayısı</var></syntax>
 <default>LimitXMLRequestBody 1000000</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>All</override>

 <usage>
     <p>Bir  XML temelli istek gövdesinin azami bayt sayısını belirler. Değer
       olarak <code>0</code> belirtildiğinde herhangi bir boyut sınaması
       yapılmaz.</p>

     <p>Örnek:</p>

     <highlight language="config">
 LimitXMLRequestBody 0
     </highlight>

 </usage>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>Location</name>
 <description>İçerdiği yönergeler sadece eşleşen URL’lere uygulanır.
 </description>
 <syntax>&lt;Location <var>URL-yolu</var>|<var>URL</var>&gt; ...
 &lt;/Location&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive type="section">Location</directive> bölüm yönergesi kapsadığı
       yönergelerin etki alanını belirtilen URL’lerle sınırlar. Bu yönerge,
       <directive type="section" module="core">Directory</directive> yönergesine
       benzer ve <code>&lt;/Location&gt;</code> yönergesi ile biten bir alt
       bölüm başlatır. <directive type="section">Location</directive> bölümleri
       yapılandırma dosyasında göründükleri sıraya göre, <directive
       type="section" module="core">Directory</directive> bölümleri ve
       <code>.htaccess</code> dosyaları okunup <directive type="section"
       module="core">Files</directive> bölümleri de işlendikten sonra işleme
       sokulurlar.</p>

     <p><directive type="section">Location</directive> bölümleri dosya
       sisteminin tamamen dışında işlem görürler. Bunun çeşitli sonuçları olur.
       En önemlisi, <directive type="section">Location</directive>
       yönergelerinin dosya sistemi konumlarına erişimi denetim altına almak
       için kullanılmaması gerekliliğidir. Aynı dosya sistemi konumuna farklı
       URL’lerle erişmek mümkün olduğundan bu tür erişim denetimleri hile ile
       atlatılabilir olacaktır.</p>

     <p>URL'nin yol bileşeni aşağıdaki koşullardan <em>herhangi birini</em>
       sağlıyorsa sarmalanan yönergeler isteğe uygulanır:
     </p>
     <ul>
       <li>Belirtilen yer URL'nin yol bileşeni ile tam olarak eşleşiyordur.
       </li>
       <li>Belirtilen yer bir bölü çizgisi öncesinde bitiyorsa URL'nin yol
         bileşeninin öneklerinden biriyle eşleşiyordur (bağlamsal bir kök dizin
         olarak).
       </li>
       <li>Belirtilen yer bir bölü çizgisi ile bitiyorsa URL'nin yol
         bileşeninin öneklerinden biriyle eşleşiyordur (bağlamsal bir kök dizin
         olarak).
       </li>
     </ul>
     <p>Aşağıdaki örnekte yer belirtimi bir bölü çizgisi ile bitirilmemiştir.
       <code>/private1</code>, <code>/private1/</code> ve
       <code>/private1/file.txt</code> istekleri için sarmalanan yönergeler
       uygulanacaktır, fakat <code>/private1other</code> isteğine
       uygulanmayacaktır.</p>

     <highlight language="config">
 &lt;Location "/private1"&gt;
     #  ...
 &lt;/Location&gt;
     </highlight>

     <p>Aşağıdaki örnekte yer belirtimi bir bölü çizgisi ile bitirilmiştir.
       <code>/private2/</code> ve <code>/private2/file.txt</code> istekleri
       için sarmalanan yönergeler uygulanacaktır, fakat <code>/private2</code>
       ve <code>/private2other</code> isteklerine uygulanmayacaktır.</p>

     <highlight language="config">
 &lt;Location "/private2<em>/</em>"&gt;
     # ...
 &lt;/Location&gt;
     </highlight>

     <note><title><directive type="section">Location</directive> ne zaman
       kullanılmalı</title>

     <p><directive type="section">Location</directive> yönergesini dosya sistemi
       dışındaki içeriğe çeşitli yönergeler uygulamak için kullanın. Dosya
       sisteminde bulunan içerik için <directive type="section"
       module="core">Directory</directive> ve <directive type="section"
       module="core">Files</directive> bölümlerini kullanın. Bunun istisnası,
       sunucunun tamamına bir yapılandırma uygulamak için kolay bir yol olan
       <code>&lt;Location "/"&gt;</code>  kullanımıdır.</p>
     </note>

     <p>Kaynağa yapılan (vekil olmayan) tüm istekler için eşleşecek URL,
       <code>/yol/</code> şeklinde bir URL yolu olmalı; <em>ne şema, ne konak ismi
       ne port ne de sorgu dizgesi içermelidir</em>. Vekil istekleri için eşleşecek
       URL ise <code>şema://sunucuadı/dosya-yolu</code> şeklinde olmalı ve önek
       içermelidir.</p>

     <p>URL içinde dosya kalıp karakterleri kullanılabilir. Dosya kalıp
       karakterleri bulunan bir dizgede bulunan <code>?</code> karakteri
       herhangi bir tek karakterle eşleşirken <code>*</code> karakteri herhangi
       bir karakter dizisi ile eşleşecektir. URL yolu içindeki / karakterleri
       ile hiçbir dosya kalıp karakteri eşleşmez.</p>

     <p>Ayrıca, <code>~</code> karakteri eşliğinde
       <glossary ref="regex">düzenli ifadeler</glossary> de kullanılabilir.
       Örneğin,</p>

     <highlight language="config">
 &lt;Location ~ "/(ek|hususi)/veri"&gt;
     #...
 &lt;/Location&gt;
     </highlight>

     <p>yönergesi <code>/ek/veri</code> ve <code>/hususi/veri</code> alt
       dizgeleriyle eşleşecektir. <directive type="section"
       module="core">LocationMatch</directive> yönergesi <directive
       type="section">Location</directive> yönergesinin düzenli ifade sürümüne
       eşdeğer davranır ve bir çok yazı tipinde <code>~</code> karakterini
       <code>-</code> karakterinden ayırmak zor olduğu için tercih edilir.</p>

     <p><directive type="section">Location</directive> işlevselliği özellikle
       <directive module="core">SetHandler</directive> yönergesi ile birlikte
       kullanışlı olur. Örneğin, durum isteklerini etkin kılmak ama sadece
       <code>example.com</code>’dan gelen isteklere izin vermek için şöyle bir
       uygulama yapabilirsiniz:</p>

     <highlight language="config">
 &lt;Location "/status"&gt;
   SetHandler server-status
   Require host example.com
 &lt;/Location&gt;
     </highlight>

     <note><title>/ (bölü çizgisi) hakkında</title>
       <p>Bölü çizgisinin URL içinde bulunduğu yere bağlı olarak özel anlamları
         vardır. Dosya sistemindeki çok sayıda yanyana kullanımının tek bir bölü
         çizgisi olarak ele alındığı duruma alışkın olanlar olabilir (yani,
         <code>/home///foo</code> ile <code>/home/foo</code> aynıdır). URL
         uzayında bunun böyle olması gerekli değildir. Eğer çok sayıda bölü
         çizgisini yanyana belirtmeniz gerekiyorsa <directive type="section"
         module="core">LocationMatch</directive> yönergesinde ve  <directive
         type="section">Location</directive> yönergesinin düzenli ifadeli
         kullanımında bunu açıkça belirtmeniz gerekir.</p>

       <p>Örneğin, <code>&lt;LocationMatch "^/abc"&gt;</code> yönergesi
         <code>/abc</code> ile eşleşecek ama <code>//abc</code> ile
         eşleşmeyecektir. <directive type="section">Location</directive>
         yönergesinin düzenli ifade içermeyen kullanımındaki davranış vekil
         isteklerinde kullanılana benzer ve doğrudan kaynağa yapılan (vekil
         olmayan) isteklerde çok sayıda bölü çizgisi dolaylı olarak tek bir bölü
         çizgisiyle eşleşecektir. Örneğin, <code>&lt;Location
         "/abc/def"&gt;</code> belirtirseniz ve istek <code>/abc//def</code>
         şeklinde olursa bu ikisi eşleşir.</p>
     </note>
 </usage>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>LocationMatch</name>
 <description>İçerdiği yönergeler sadece düzenli ifadelerle eşleşen URL’lere
 uygulanır.</description>
 <syntax>&lt;LocationMatch
     <var>düzifade</var>&gt; ... &lt;/LocationMatch&gt;</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive type="section">LocationMatch</directive> yönergesi içerdiği
       yönergelerin etki alanını <directive module="core" type="section"
       >Location</directive> yönergesinin yaptığı gibi belirtilen URL’lerle
       sınırlar. Ancak argüman olarak basit bir dizge değil bir <glossary
       ref="regex">düzenli ifade</glossary> alır. Örneğin,</p>

     <highlight language="config">
 &lt;LocationMatch "/(ek|hususi)/veri"&gt;
     # ...
 &lt;/LocationMatch&gt;
     </highlight>

     <p>yönergesi <code>/ek/veri</code> ve <code>/hususi/veri</code> alt
       dizgeleriyle eşleşecektir.</p>

     <note><p>Eğer hedef, <code>/ek/veri</code> içeren değil de
         <code>/ek/veri</code> ile başlayan bir URL ise düzenli ifadenin önüne
         <code>^</code> getirmek gerekir.</p>

     <highlight language="config">
 &lt;LocationMatch "^/(ek|hususi)/veri"&gt;
     </highlight>
     </note>

     <p>2.4.8 itibariyle, isimli gruplar ve geriye başvurular elde edilmekte
       olup ilgili isim büyük harfe çevrildikren sonra "MATCH_" ile
       öncelendikten sonra ortama yazılmaktadır. Böylece yol elemanlarına
       <module>mod_rewrite</module> gibi modüllerden veya <a
       href="../expr.html">düzenli ifadelerden</a> başvurmak mümkün
       kılınmıştır. Karışıklığı önlemek için, numaralı (isimsiz) geriye
       başvurular yoksayılmaktadır. Bunların yerine isimli geriye başvurular
       kullanılmalıdır.</p>

     <highlight language="config">
 &lt;LocationMatch "^/combined/(?&lt;sitename&gt;[^/]+)"&gt;
     require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
 &lt;/LocationMatch&gt;
     </highlight>
 </usage>

 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>LogLevel</name>
 <description>Hata günlüklerinin ayrıntı seviyesini belirler.</description>
 <syntax>LogLevel [<var>modül</var>:]<var>seviye</var>
     [<var>modül</var>:<var>seviye</var>] ...
 </syntax>
 <default>LogLevel warn</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context></contextlist>
 <compatibility>Modül ve dizin bağlamındaki yapılandırmalar Apache HTTP
     Sunucusunun 2.3.6 ve sonraki sürümlerinde
     kullanılabilmektedir.</compatibility>

 <usage>
     <p><directive>LogLevel</directive> yönergesi hata günlüklerine kaydedilen
       hata iletilerinde hangi ayrıntılara yer verileceğini belirler (<directive
       module="core">ErrorLog</directive> yönergesine bakınız). En yüksek önem
       derecesinden başlayarak olası <var>seviye</var> değerleri aşağıda
       sıralanmıştır:</p>

     <table border="1">
     <columnspec><column width=".2"/><column width=".3"/><column width=".5"/>
     </columnspec>
       <tr>
         <th><strong>Seviye</strong> </th>
         <th><strong>Açıklama</strong> </th>
         <th><strong>Örnek</strong> </th>
       </tr>

       <tr>
         <td><code>emerg</code> </td>
         <td>Acil durumlar - sistem kullanışsız.</td>
         <td>"Child cannot open lock file. Exiting"<br />(Alt süreç kilit
           dosyasını açamıyor. Çıkılıyor)</td>
       </tr>

       <tr>
         <td><code>alert</code> </td>
         <td>Ne yapılacaksa beklemeden yapılmalı.</td>
         <td>"getpwuid: couldn't determine user name from uid"<br />(getpwuid:
           Kullanıcı ismi numarasından saptanamadı)</td>
       </tr>

       <tr>
         <td><code>crit</code> </td>
         <td>Kriz durumları.</td>
         <td>"socket: Failed to get a socket, exiting child"<br />(socket: bir
           soket alınamadı, alt süreç çıkıyor)</td>
       </tr>

       <tr>
         <td><code>error</code> </td>
         <td>Hata durumları.</td>
         <td>"Premature end of script headers"<br />(Betik başlıkları
           beklenmedik şekilde bitti)</td>
       </tr>

       <tr>
         <td><code>warn</code> </td>
         <td>Uyarı durumları.</td>
         <td>"child process 1234 did not exit, sending another
           SIGHUP"<br />(1234 alt süreci çıkmadı, başka bir SIGHUP
           gönderiliyor)</td>
       </tr>

       <tr>
         <td><code>notice</code> </td>
         <td>Normal fakat önemli durum.</td>
         <td>"httpd: caught SIGBUS, attempting to dump core in
           ..."<br />(httpd: SIGBUS alındı, core dökümlenmeye çalışılıyor:
           ...)</td>
       </tr>

       <tr>
         <td><code>info</code> </td>
         <td>Bilgilendirme.</td>
         <td>"Server seems busy, (you may need to increase
           StartServers, or Min/MaxSpareServers)..."<br />(Sunucu meşgul
           görünüyor, (StartServers veya Min/MaxSpareServers değerlerini
           arttırmanız gerekebilir)...)</td>
       </tr>

       <tr>
         <td><code>debug</code> </td>
         <td>Hata ayıklama seviyesi iletileri</td>
         <td>"Opening config file ..."<br />(... yapılandırma dosyası
           açılıyor)</td>
       </tr>
       <tr>
         <td><code>trace1</code> </td>
         <td>İz sürme iletileri</td>
         <td>"proxy: FTP: control connection complete"<br />(vekil: FTP:
           denetim bağlantısı sağlandı)</td>
       </tr>
       <tr>
         <td><code>trace2</code> </td>
         <td>İz sürme iletileri</td>
         <td>"proxy: CONNECT: sending the CONNECT request to the remote
           proxy"<br />(vekil: CONNECT: uzak vekile CONNECT isteği
           gönderiliyor)</td>
       </tr>
       <tr>
         <td><code>trace3</code> </td>
         <td>İz sürme iletileri</td>
         <td>"openssl: Handshake: start"</td>
       </tr>
       <tr>
         <td><code>trace4</code> </td>
         <td>İz sürme iletileri</td>
         <td>"read from buffered SSL brigade, mode 0, 17 bytes"<br />(tamponlu
           SSL gruplamasından okuma, kip 0, 17 baytİz sürme iletileri</td>
       </tr>
       <tr>
         <td><code>trace5</code> </td>
         <td>İz sürme iletileri</td>
         <td>"map lookup FAILED: map=rewritemap key=keyname"<br />(eşleşme
           araması BAŞARISIZ: map=rewritemap key=keyname)</td>
       </tr>
       <tr>
         <td><code>trace6</code> </td>
         <td>İz sürme iletileri</td>
         <td>"cache lookup FAILED, forcing new map lookup"<br />(arabellek
           araması BAŞARISIZ, yeni bir eşleşme araması başlatılıyor)</td>
       </tr>
       <tr>
         <td><code>trace7</code> </td>
         <td>İz sürme iletileri, büyük miktarda veri dökümü</td>
         <td>"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"</td>
       </tr>
       <tr>
         <td><code>trace8</code> </td>
         <td>İz sürme iletileri, büyük miktarda veri dökümü</td>
         <td>"| 0000: 02 23 44 30 13 40 ac 34 df 3d bf 9a 19 49 39 15 |"</td>
       </tr>
     </table>

     <p>Belli bir seviye belirtildiğinde daha yüksek seviyeden iletiler de
       raporlanır. Örneğin, <code>LogLevel info</code> belirtildiğinde
       <code>notice</code> ve <code>warn</code> günlük seviyelerinin iletileri
       ayrıca raporlanacaktır.</p>

     <p>En az <code>crit</code> seviyesinin kullanılması önerilir.</p>

     <p>Örnek:</p>

     <highlight language="config">
 LogLevel notice
     </highlight>


     <note><title>Ek Bilgi</title>
       <p>Günlük iletileri normal bir dosyaya yazılırken <code>notice</code>
         seviyesinden iletiler engellenemez ve dolayısıyla daima raporlanırlar.
         Ancak, günlük kaydı <code>syslog</code> kullanılarak yapılıyorsa bu
         uygulanmaz.</p>
     </note>

     <p>Bir modül ismi olmaksızın bir seviye belirtmek seviyeyi bu seviyedeki
       tüm modüller için sıfırlayacaktır. Bir seviyyi bir modül ismiyle
       birlikte belirtmek seviyeyi sadece bu modül için sıfırlayacaktır. Modül
       ismi olarak, modülün kaynak dosyası ismini, modül kimliği veya
       <code>_module</code> sonekli modül ismi belirtmek mümkündür.
       Yani, aşağıdaki üç belirtim eşdeğerdedir:</p>

     <highlight language="config">
 LogLevel info ssl:warn
 LogLevel info mod_ssl.c:warn
 LogLevel info ssl_module:warn
     </highlight>

     <p>Ayrıca seviyeyi dizin bağlamında değiştirmek de mümkündür:</p>

     <highlight language="config">
 LogLevel info
 &lt;Directory "/usr/local/apache/htdocs/app"&gt;
   LogLevel debug
 &lt;/Directory&gt;
     </highlight>

     <note>Dizin bağlamında günük seviyesi yapılandırması sadece istek
       çözümlendikten ve istek dizinle ilişkilendirildikten sonra günlüklenen
       iletileri etkiler. Bağlantı veya sunucu ile ilişkilendirilmemiş günlük
       iletileri etkilenmez.</note>
 </usage>
 <seealso><directive module="core">ErrorLog</directive></seealso>
 <seealso><directive module="core">ErrorLogFormat</directive></seealso>
 <seealso><a href="../logs.html">Apache HTTP Server Log Files</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>MaxKeepAliveRequests</name>
 <description>Bir kalıcı bağlantıda izin verilen istek sayısı</description>
 <syntax>MaxKeepAliveRequests <var>sayı</var></syntax>
 <default>MaxKeepAliveRequests 100</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>MaxKeepAliveRequests</directive> yönergesi <directive
       module="core" >KeepAlive</directive> etkinken bağlantı başına izin
       verilecek istek sayısını sınırlar. Değer olarak <code>0</code>
       belirtilirse istek sayısı sınırsız olur. Sunucu başarımını yüksek tutmak
       için yüksekçe bir değer belirtmenizi öneririz.</p>

     <p>Örnek:</p>

     <highlight language="config">
 MaxKeepAliveRequests 500
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>MaxRanges</name>
 <description>Özkaynağın tamamını döndürmeden önce izin verilen aralık sayısı</description>
 <syntax>MaxRanges default | unlimited | none |
   <var>aralık-sayısı</var></syntax>
 <default>MaxRanges 200</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context>
 </contextlist>
 <compatibility>Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde
     kullanılabilmektedir.</compatibility>

 <usage>
     <p><directive>MaxRanges</directive> yönergesi, sunucunun istemciye
       göndermeye gönüllü olacağı HTTP Range'lerinin sayısını sınırlar. İzin
       verilenden daha fazlası istenmişse özkaynağın tamamı döndürülür.</p>

     <dl>
       <dt><strong>default</strong></dt>
       <dd>HTTP Range'lerinin sayısını derleme sırasında belirlenen öntanımlı
         200 değeriyle sınırlar.</dd>

       <dt><strong>none</strong></dt>
       <dd>Range başlıkları yoksayılır.</dd>

       <dt><strong>unlimited</strong></dt>
       <dd>Sunucunun sağlamaya gönüllü olacağı HTTP Range'lerinin sayısı
         sınırlanmaz.</dd>

       <dt><var>aralık-sayısı</var></dt>
       <dd>Sunucunun sağlamaya gönüllü olacağı HTTP Range'lerinin azami
         sayısını ifade eden pozitif bir tamsayı.</dd>
     </dl>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>MaxRangeOverlaps</name>
 <description>Özkaynağın tamamını döndürmeden önce izin verilen üst üste binen
     aralık sayısı (<code>100-200,150-300</code> gibi)</description>
 <syntax>MaxRangeOverlaps default | unlimited | none |
   <var>aralık-sayısı</var></syntax>
 <default>MaxRangeOverlaps 20</default>
 <contextlist><context>server config</context><context>virtual host</context>
     <context>directory</context>
 </contextlist>
 <compatibility>Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde
     kullanılabilmektedir.</compatibility>

 <usage>
     <p><directive>MaxRangeOverlaps</directive> yönergesi, sunucunun istemciye
       göndermeye gönüllü olacağı üst üste binen HTTP Range'lerinin sayısını
       sınırlar. İzin verilenden daha fazlası istenmişse özkaynağın tamamı
       döndürülür.</p>

     <dl>
         <dt><strong>default</strong></dt>
         <dd>Üst üste binen HTTP Range'lerinin sayısını derleme sırasında
           belirlenen öntanımlı 20 değeriyle sınırlar.</dd>

         <dt><strong>none</strong></dt>
         <dd>Üst üste binen Range başlıkları yoksayılır.</dd>

         <dt><strong>unlimited</strong></dt>
         <dd>Sunucunun sağlamaya gönüllü olacağı üst üste binen HTTP
           Range'lerinin sayısı sınırlanmaz.</dd>

         <dt><var>aralık sayısı</var></dt>
         <dd>Sunucunun sağlamaya gönüllü olacağı üst üste binen HTTP
           Range'lerinin azami sayısını ifade eden pozitif bir tamsayı.</dd>
     </dl>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>MaxRangeReversals</name>
 <description>Özkaynağın tamamını döndürmeden önce izin verilen ters sıralı
     aralık sayısı (<code>100-200,50-70</code> gibi)</description>
 <syntax>MaxRangeReversals default | unlimited | none |
     <var>aralık-sayısı</var></syntax>
 <default>MaxRangeReversals 20</default>
 <contextlist><context>server config</context><context>virtual host</context>
     <context>directory</context>
 </contextlist>
 <compatibility>Apache HTTP Sunucusunun 2.3.15 ve sonraki sürümlerinde
     kullanılabilmektedir.</compatibility>

 <usage>
     <p>The <directive>MaxRangeReversals</directive> yönergesi, sunucunun
       istemciye göndermeye gönüllü olacağı ter sıralı HTTP Range'lerinin
       sayısını sınırlar. İzin verilenden daha fazlası istenmişse
       özkaynağın tamamı döndürülür.</p>

     <dl>
         <dt><strong>default</strong></dt>
         <dd>Ters sıralı HTTP Range'lerinin sayısını derleme sırasında
           belirlenen öntanımlı 20 değeriyle sınırlar.</dd>

         <dt><strong>none</strong></dt>
         <dd>Ters sıralı Range başlıkları yoksayılır.</dd>

         <dt><strong>unlimited</strong></dt>
         <dd>Sunucunun sağlamaya gönüllü olacağı ters sıralı HTTP
           Range'lerinin sayısı sınırlanmaz.</dd>

         <dt><var>aralık-sayısı</var></dt>
         <dd>Sunucunun sağlamaya gönüllü olacağı ters sıralı HTTP
           Range'lerinin azami sayısını ifade eden pozitif bir tamsayı.</dd>
     </dl>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>Mutex</name>
 <description>Muteks mekanizmasını ve kilit dosyası dizinini tüm muteksler veya belirtilenler için yapılandırır</description>
 <syntax>Mutex <var>mekanizma</var> [default|<var>muteks-ismi</var>] ... [OmitPID]</syntax>
 <default>Mutex default</default>
 <contextlist><context>server config</context></contextlist>
 <compatibility>Apache HTTP Sunucusunun 2.3.4 ve sonraki sürümlerinde
     kullanılabilmektedir.</compatibility>

 <usage>
     <p><directive>Mutex</directive> yönergesi httpd ve diğer modüllerin
       özkaynaklara erişimi dizgeleştirmekte kullandıkları mekanizmanın yanında
       isteğe bağlı olarak kilit dosyasının yerini belirler. İlk değiştirge
       olarak <code>default</code> belirtilirse tüm mutekslerin ayarları
       değişir; ikinci değiştirge olarak bir muteks ismi belirtilirse (aşağıdaki
       tabloya bakın) yalnızca bu muteksin öntanımlıları değişir.</p>

     <p><directive>Mutex</directive> yönergesi genelde aşağıdaki istisnai
       durumlarda kullanılır:</p>

     <ul>
         <li>İşlevsel veya başarımsal bir soruna sahip <glossary>APR</glossary>
           tarafından öntanımlı mekanizma seçildiği takdirde muteks
           mekanizmasını değiştirmek için</li>

         <li>Öntanımlı dizin, kilitlemeyi desteklemediği takdirde dosya tabanlı
           muteksler tarafından kullanılan dizini değiştirmek için</li>
     </ul>

     <note><title>Destekleyen modüller</title>
     <p>Bu yönerge sadece <code>ap_mutex_register()</code> API'si kullanılarak
       çekirdek sunucuda imlenmiş muteksleri yapılandırır. httpd ile birlikte
       dağıtılan tüm modüller <directive>Mutex</directive> yönergesini
       destekler, fakat üçüncü parti modüllerin hepsi desteklemeyebilir. Bu
       yönergenin desteklenip desteklenmediğini öğrenmek için üçüncü parti
       modülün belgelerini inceleyin; destekliyorsa muteks ad(lar)ı
       belirtilmiştir.</p>
     </note>

     <p>Kullanılabilen muteks <em>mekanizmaları</em>:</p>
     <ul>
         <li><code>default | yes</code>
         <p><glossary>APR</glossary> tarafından saptanan öntanımlı kilitleme
           gerçeklenimini seçer. Öntanımlı kilitleme gerçeklenimi
           <program>httpd</program> <code>-V</code> seçeneği ile çalıştırılarak
           öğrenilebilir.</p></li>

         <li><code>none | no</code>
         <p>Muteksi etkin şekilde iptal eder. Buna bir mutekste izin
           verilebilmesi için modülün bunun geçerli bir seçim olduğunu
           belirtmesi gerekir. Daha fazla bilgi için modül belgelerini
           inceleyin.</p></li>

         <li><code>posixsem</code>
         <p>POSIX semaforuna dayalı bir muteks çeşididir.</p>
         <note type="warning"><title>Uyarı</title>
         <p>Süreçteki bir evre muteks parçalama arızalarını tutuyorsa,
           httpd'nin çökmesi sonucu, semafor sahipliği geri kazanılmaz.</p>
         </note>
         </li>

         <li><code>sysvsem</code>
         <p>SystemV IPC semaforuna dayalı bir muteks çeşididir.</p>
         <note type="warning"><title>Uyarı</title>
         <p>Semafor geri kazanılmadan süreçler çökerse SysV semaforlarının
           "sızıntı" yapması mümkündür.</p>
         </note>
         <note type="warning"><title>Güvenlik</title>
         <p>Semafor API'si, HTTP sunucusu ile aynı kullanıcı kimliği altında
           çalışan bir CGI (<em>örn</em>, <program>suexec</program> veya
           <code>cgiwrapper</code> gibi bir araç kullanmıyorsanız bütün
           CGI'ler) tarafından hizmet reddi saldırısı yapılmasına izin
           verir.</p>
         </note>
         </li>

         <li><code>sem</code>
         <p>POSIX ve SystemV IPC semaforları arasından kullanılabilir "en iyi"
           semafor gerçeklenimini seçer.</p></li>

         <li><code>pthread</code>
         <p>Süreç çaprazlamalı POSIX evre mutekslerine dayalı bir muteks
           çeşididir.</p>
         <note type="warning"><title>Uyarı</title>
         <p>Çoğu sistemde, bir çocuk süreç bu gerçeklenim tarafından kullanılan
           bir muteksi tutarken olağandışı bir şekilde sonlanırsa httpd donar
           ve isteklere yanıt vermeyi durdurur. Bu olduğunda sunucuyu bu
           durumdan kurtarmak için elle yeniden başlatmak gerekir.</p>
         <p>Bu duruma karşı bir mekanizma sağlayan Solaris ve Linux dikkate
           değer bir istisnadır. Bu mekanizma, bir muteksi tutan bir çocuk
           süreç olağandışı bir şekilde sonlandıktan sonra muteksin
           kurtarılmasını sağlar.</p>
         <p>Sisteminiz POSIX uyumluysa veya
           <code>pthread_mutexattr_setrobust_np()</code> işlevini
           sağlıyorsa <code>pthread</code> seçeneğini rahatça
           kullanabilirsiniz.</p>
         </note>
         </li>

         <li><code>fcntl:/path/to/mutex</code>
         <p>Muteks olarak <code>fcntl()</code> işlevini ve fiziksel bir (lock-)
           dosyasını kullanan bir muteks çeşididir.</p>
         <note type="warning"><title>Uyarı</title>
         <p>Bu mekanizmaya dayalı çok sayıda muteks, çok evreli ve çok süreçli
           ortamlarda kullanıldığında, örneğin Solaris'te olduğu gibi
           <code>fcntl()</code> evrelerden bihaberse, geçerli muteks
           işlemlerinde donma hataları (EDEADLK) raporlanabilir.</p>
         </note>
         </li>

         <li><code>flock:/path/to/mutex</code>
         <p><code>flock()</code> işlevinin dosya kilitlemeyi sağlaması dışında
           <code>fcntl:/path/to/mutex</code> yöntemine benzer.</p></li>

         <li><code>file:/path/to/mutex</code>
         <p><code>fcntl</code> ve <code>flock</code> arasından kullanılabilir
           "en iyi" dosya kilitleme gerçeklenimini seçer.</p></li>
     </ul>

     <p>Çoğu mekanizma, yalnız kendilerini destekleyen platformlarda
       <glossary>APR</glossary> tarafından da destekleniyorsa kullanılabilir.
       Tüm platformlarda kullanılamayan mekanizmalar <em>posixsem</em>,
       <em>sysvsem</em>, <em>sem</em>, <em>pthread</em>, <em>fcntl</em>,
       <em>flock</em> ve <em>file</em> mekanizmalarıdır.</p>

     <p><em>fcntl</em> ve <em>flock</em> dosya tabanlı mekanizmaları ile bir
       yol sağlandığı takdirde bu, kilit dosyasının oluşturulacağı dizindir.
       Öntanımlı dizin, httpd'nin çalışma anı dizini <directive
       module="core">ServerRoot</directive>'a görelidir.
       <code>/path/to/mutex</code> için daima bir yerel diskteki dosya sistemi
       kullanılır, asla NFS- veya AFS gibi bir ağ dosya sistemi kullanılmaz.
       Dosya ismi daima muteks ismi ile başlar, buna modül tarafından sağlanan
       isteğe bağlı bir aşama dizgesi eklenebilir, <code>OmitPID</code> değeri
       belirtilmemişse httpd ebeveyn sürecinin süreç kimliği buna eklenerek
       dosya ismi eşsiz kılınır. Böylece, çok sayıda httpd süreci aynı kilit
       dosyası dizinini paylaştığı durumda çakışmalar önlenmiş olur. Örneğin,
       muteks ismi <code>mpm-accept</code> ise ve kilit dosyası dizini
       <code>/var/httpd/locks</code> ise ve ebeveyn süreç kimliği 12345 ise bu
       httpd sürecine ait kilit dosyası ismi
       <code>/var/httpd/locks/mpm-accept.12345</code> olurdu.</p>

     <note type="warning"><title>Güvenlik</title>
     <p>Muteks dosyalarını herkesin yazabildiği <code>/var/tmp</code> gibi
       dizinlere koymaktan <em>kaçınmak</em> en iyisidir. Örneğin, birinin aynı
       dizinde oluşturmaya çalıştığı bir dosya ile aynı isimde bir kilit
       dosyasını sunucunun da oluşturmaya çalıştığı durumda sunucu engellenerek
       bir hizmet reddi saldırısı gerçekleştirilmiş gibi olur.</p>
     </note>

     <p>httpd ve birlikte dağıtılan modüller tarafından kullanılan mutekslerin
       isimleri:</p>

     <table border="1" style="zebra">
         <tr>
             <th>Muteks ismi</th>
             <th>Modül(ler)</th>
             <th>Korunan özkaynak</th>
         </tr>
         <tr>
             <td><code>mpm-accept</code></td>
             <td><module>prefork</module> ve <module>worker</module> MPM'leri
             </td>
             <td>Gürleyen sürü sorunundan kaçınmak için gelen bağlantılar; daha
               fazla bilgi için <a href="../misc/perf-tuning.html">başarımın
               arttırılması</a>  belgesine bakın.</td>
         </tr>
         <tr>
             <td><code>authdigest-client</code></td>
             <td><module>mod_auth_digest</module></td>
             <td>Paylaşımlı bellekteki istemci listesi</td>
         </tr>
         <tr>
             <td><code>authdigest-opaque</code></td>
             <td><module>mod_auth_digest</module></td>
             <td>Paylaşımlı bellekteki sayaç</td>
         </tr>
         <tr>
             <td><code>ldap-cache</code></td>
             <td><module>mod_ldap</module></td>
             <td>LDAP sonuç arabelleği</td>
         </tr>
         <tr>
             <td><code>rewrite-map</code></td>
             <td><module>mod_rewrite</module></td>
             <td>Çoklu isteklerdeki birbirine karışmış G/Ç'tan kaçınmak için
               harici eşleştirme progamlarıyla iletişim</td>
         </tr>
         <tr>
             <td><code>ssl-cache</code></td>
             <td><module>mod_ssl</module></td>
             <td>SSL oturum arabelleği</td>
         </tr>
         <tr>
             <td><code>ssl-stapling</code></td>
             <td><module>mod_ssl</module></td>
             <td>OCSP zımbalama yanıtı arabelleği</td>
         </tr>
         <tr>
             <td><code>watchdog-callback</code></td>
             <td><module>mod_watchdog</module></td>
             <td>Bir istemci modülünün geri çağırım işlevi</td>
         </tr>
     </table>

     <p><code>OmitPID</code> seçeneği, httpd ebeveyn süreç kimliğinin kilit
       dosyası ismine eklenmesini engeller.</p>

     <p>Aşağıdaki örnekte, <code>mpm-accept</code> muteksinin mekanizmasının
       derleme sırasındaki öntanımlısı, kilit dosyasının oluşturulacağı dizinin
       <code>/var/httpd/locks</code> olarak belirtildiği <code>fcntl</code>
       mekanizmasıyla değiştirilmektedir.Tüm diğer mutekslerin derleme anı
       öntanımlı mekanizması ise <code>sysvsem</code> ile
       değiştirilmektedir.</p>

     <highlight language="config">
 Mutex sysvsem default
 Mutex fcntl:/var/httpd/locks mpm-accept
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>NameVirtualHost</name>
 <description>ÖNERİLMİYOR: İsme dayalı sanal konaklar için IP adresi belirtir</description>
 <syntax>NameVirtualHost <var>adres</var>[:<var>port</var>]</syntax>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p>2.3.11 öncesinde, <directive>NameVirtualHost</directive> yönergesi,
       isme dayalı sanal konaklar için belli bir IP adresi ve port çiftini
       sunucuya tanıtmak için gerekliydi. 2.3.11 ve sonrasında, bir IP adresi
       ve port çifti  her zaman çok sayıda sanal konakta kullanılabilmekte,
       isme dayalı sanal barındırma bu adres için özdevinimli olarak etkin
       kılınmaktadır.</p>

     <p>Bu yönerge şu an etkisizdir.</p>
 </usage>
 <seealso><a href="../vhosts/">Apache Sanal Konak Belgeleri</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>Options</name>
 <description>Belli bir dizinde geçerli olacak özellikleri yapılandırır.
 </description>
 <syntax>Options
     [+|-]<var>seçenek</var> [[+|-]<var>seçenek</var>] ...</syntax>
 <default>Options FollowSymlinks</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>Options</override>
 <compatibility>2.3.11 sürümünde öntanımlı değer All değiştirilip FollowSymlinks yapıldı.</compatibility>

 <usage>
     <p><directive>Options</directive> yönergesi belli bir dizinde hangi
        sunucu özelliklerinin etkin olacağını (veya olmayacağını)
        belirler.</p>

     <p><var>seçenek</var> olarak hiçbir ek özellik etkin olmayacaksa
       <code>None</code>, aksi takdirde aşağıdakilerden biri veya bir kaçı
       belirtilir:</p>

     <dl>
       <dt><code>All</code></dt>
       <dd><code>MultiViews</code> hariç tüm seçenekler.</dd>

       <dt><code>ExecCGI</code></dt>
       <dd><module>mod_cgi</module> kullanan CGI betiklerinin çalışmasına izin
         verilir.</dd>

       <dt><code>FollowSymLinks</code></dt>
       <dd>Sunucu bu dizindeki sembolik bağları izler. Bu öntanımlıdır.
       <note>
       <p>Sembolik bağlar izlense bile <directive type="section"
         module="core">Directory</directive> bölümleriyle eşleşen dosya
        yolları değiştirilmez.</p>
       <p><code>FollowSymLinks</code> ve
         <code>SymLinksIfOwnerMatch</code> <directive
         module="core">Options</directive> sadece <directive
         type="section" module="core">Directory</directive> bölümlerinde veya
         <code>.htaccess</code> dosyaları içinde çalışır.</p>
       <p>Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu
         olduğundan bu seçeneğin yokluğu bir güvenlik sınırlaması olarak
         değerlendirilmemelidir.</p>
       </note></dd>

       <dt><code>Includes</code></dt>
       <dd><module>mod_include</module> tarafından sağlanan sunucu taraflı
         içeriklere izin verilir.</dd>

       <dt><code>IncludesNOEXEC</code></dt>
       <dd>Sunucu taraflı içeriklere izin verilir fakat <code>#exec cmd</code>
         ve <code>#exec cgi</code> iptal edilir. Ancak, <directive
         module="mod_alias">ScriptAlias</directive>’lı dizinlerdeki CGI
         betikleri için <code>#include virtual</code> hala mümkün olacaktır.</dd>

       <dt><code>Indexes</code></dt>
       <dd>İstenen URL bir dizin ile eşleşiyorsa ve bu dizin için bir <directive
         module="mod_dir">DirectoryIndex</directive> (<code>index.html</code>
         gibi) belirtilmemişse <module>mod_autoindex</module> bu dizinin
         biçimlenmiş bir listesini döndürecektir.</dd>

       <dt><code>MultiViews</code></dt>
       <dd><module>mod_negotiation</module> kullanılarak <a
         href="../content-negotiation.html">içerik uzlaştırmalı</a> çok
         görünümlü içeriğe izin verilir.
       <note><title>Bilgi</title> <p><module>mod_negotiation</module>
         karşılaştırmak değerlendirmek için gerçek özkaynaklara ihtiyaç
         duyduğundan <directive module="core" type="section"
         >Directory</directive> yönergesinde belirtilendan farklı bir yer
         ayarlanırsa bu seçenek yoksayılır.</p></note>
       </dd>

       <dt><code>SymLinksIfOwnerMatch</code></dt>
       <dd>Sunucu sembolik bağları sadece sembolik bağın hedefi ile bulunduğu
         dizinin sahibinin aynı kullanıcı olması halinde izleyecektir.

       <p><code>FollowSymLinks</code> ve
       <code>SymLinksIfOwnerMatch</code> <directive
       module="core">Options</directive> sadece <directive
       type="section" module="core">Directory</directive> bölümlerinde veya
       <code>.htaccess</code> dosyaları içinde çalışır.</p>

       <p>Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu
         olduğundan bu seçenek bir güvenlik sınırlaması olarak
         değerlendirilmemelidir.</p>
       </dd>
     </dl>

     <p>Normalde, bir dizine çok sayıda <directive>Options</directive>
       uygulanabilirse de, dizine en uygun olanı uygulanıp diğerleri yok
       sayılır; seçenekler katıştırılmaz (bkz, <a href="../sections.html#merging"
       >Bölümler Nasıl Katıştırılır?</a>). Bununla birlikte, önüne bir
       <code>+</code> veya <code>-</code> simgesi konmuş seçenekler varsa, o
       seçenekler katıştırılır. Önüne <code>+</code> konmuş seçenekler
       mevcutlara eklenirken <code>-</code> konmuş seçenekler silinir.</p>

     <note><title>Bilgi</title>
     <p><code>+</code> veya <code>-</code> imli seçenekler içeren
       <directive>Options</directive> ile imsiz seçenekler içerenlerin karışık
       olarak kullanılması aslında geçersiz bir sözdizimi olup sunucunun
       başlatılması sırasında sözdizimi denetiminin çıkmasıyla reddedilir.</p>
     </note>

     <p>Örneğin, <code>+</code> ve <code>-</code> imleri olmaksızın,</p>

     <highlight language="config">
 &lt;Directory "/web/docs"&gt;
   Options Indexes FollowSymLinks
 &lt;/Directory&gt;

 &lt;Directory "/web/docs/spec"&gt;
   Options Includes
 &lt;/Directory&gt;
     </highlight>

     <p>yapılandırmasıyla <code>/web/docs/spec</code> dizininde sadece
       <code>Includes</code> seçeneği etkin olacaktır. Bununla birlikte, ikinci
       <directive>Options</directive> yönergesinde <code>+</code> ve
       <code>-</code> imleri kullanılırsa,</p>

     <highlight language="config">
 &lt;Directory "/web/docs"&gt;
   Options Indexes FollowSymLinks
 &lt;/Directory&gt;

 &lt;Directory "/web/docs/spec"&gt;
   Options +Includes -Indexes
 &lt;/Directory&gt;
     </highlight>

     <p>yapılandırmasıyla <code>/web/docs/spec</code> dizininde
       <code>FollowSymLinks</code> ve <code>Includes</code> seçenekleri etkin
       olacaktır.</p>

     <note><title>Ek Bilgi</title>
       <p><code>-IncludesNOEXEC</code> veya <code>-Includes</code> kullanımı,
         önceki ayarların ne olduğuna bakılmaksızın sunucu taraflı içeriğin
         tamamen iptaline sebep olur.</p>
     </note>

     <p>Herhangi bir başka değer belirtilmedikçe <code>FollowSymlinks</code>
       öntanımlıdır.</p>
 </usage>
 </directivesynopsis>

  <directivesynopsis>
 <name>Protocol</name>
 <description>Dinlenen bir soket için protokol</description>
 <syntax>Protocol <var>protokol</var></syntax>
 <contextlist><context>server config</context>
 <context>virtual host</context></contextlist>
 <compatibility>Apache httpd 2.1.5 ve sonrasında kullanılabilmektedir.
     Windows'ta ise Apache httpd 2.3.3 ve sonrasında
     kullanılabilmektedir.
 </compatibility>

 <usage>
     <p>Bu yönerge dinlenen belli bir soket için kullanılacak protokolü
       belirler. Belirtilen protokol bir isteği hangi modülün ele alacağını ve
       <directive>AcceptFilter</directive> yönergesiyle yapılan özel
       eniyilemelere uygulanacak protokolü belirler.</p>

     <p>Bir protokol belirtme ihtiyacını sadece standartdışı portlarda
       çalışıyorsanız duyarsınız. Aksi takdirde, <code>http</code> protokolünün
       port 80'i, <code>https</code>'in ise 443'ü kullandığı varsayılır.</p>

     <p>Örneğin, <code>https</code>'i standartdışı bir portta çalıştırmak
       isterseniz protokolü şöyle belirtebilirsiniz:</p>

     <highlight language="config">
 Protocol https
     </highlight>

     <p>Protokolü <directive module="mpm_common">Listen</directive>
        yönergesini kullanarak da belirtebilirsiniz.</p>
 </usage>
 <seealso><directive>AcceptFilter</directive></seealso>
 <seealso><directive module="core">AcceptFilter</directive></seealso>
 <seealso><directive module="mpm_common">Listen</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>Protocols</name>
 <description>Sunucu/sanal konak için kullanılabilecek protokoller</description>
 <syntax>Protocols <var>protokol</var> ...</syntax>
 <default>Protocols http/1.1</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>
 <compatibility>Sadece Apache 2.4.17 ve sonrasında kullanılabilir.</compatibility>

 <usage>
     <p>Bu yönerge bir sunucu/sanal konak için kullanılabilecek
       protokolleri belirtmekte kullanılır. Bu liste, bir istemcinin bir
       sanal konak veya sunucu ile uzlaşabilmesini sağlayan prokolleri
       belirler.</p>

     <p>Bir sanal konak veya sunucuda kullanılabilecek protolleri
       çeşitlendirmek isterseniz bu protokolleri belirtmeniz gerekir.
       1.0 ve 0.9 istemcilerle uyumlu olan http/1.1 protokolü
       öntanımlıdır.</p>

     <p>Örneğin, bir sunucunun TLS'li HTTP/2 protokolünü desteklemesini
       şöyle sağlayabilirsiniz:</p>

     <highlight language="config">
 Protocols h2 http/1.1
     </highlight>

     <p>Geçerli protokoller, http ve https bağlantıları için
        <code>http/1.1</code> htps bağlantıları için <code>h2</code> ve
        http bağlantıları için <code>h2c</code> protokolleridir. Modüller
        başka protokollerin de etkinleştirilmesini gerektirebilir.</p>

     <p>Kullanımından vazgeçilmiş protokollerin silinmesi gerekmez. Böyle
        protokol isimleri basitçe yoksayılır.</p>

     <p>Ana sunucu için belirtilen protokoller, kendi protokol yönergesi
        olmayan sanal konaklar için de geçerlidir. Diğer yandan sanal
        konaklarda protokol belirtilmesi ana sunucuda belirtien
        protollerin bu sanal konaklarda geçersiz olmasına sebep olur.
     </p>

 </usage>
 <seealso><directive module="core">ProtocolsHonorOrder</directive></seealso>
 </directivesynopsis>


 <directivesynopsis>
 <name>ProtocolsHonorOrder</name>
 <description>Uzlaşma sırasında protokollerin öncelik sırasını belirler</description>
 <syntax>ProtocolsHonorOrder On|Off</syntax>
 <default>ProtocolsHonorOrder On</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>
 <compatibility>Sadece Apache 2.4.17 ve sonrasında kullanılabilir.</compatibility>

 <usage>
     <p>Sunucuda <directive>Protocols</directive> yönergesinde listelemiş
       protokollerin mi yoksa istemcinin protokol listesinin mi öncelikli
       olacağı bu yönerge ile belirtilir.</p>

     <p>Off belirtilirse, istemcinin protokol listesi sunucu
       yapılandırmasındaki sıralamanın önüne geçer.</p>

     <p><directive>ProtocolsHonorOrder</directive> yönergesine <code>on</code>
          belirtilirse (öntanımlıdır), istemicinin protokol sıralaması dikkate
          alınmaz ve protokol uzlaşımının sonucunu sunucu ayarlarındaki
          sıralama belirler.</p>

 </usage>
 <seealso><directive module="core">Protocols</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>RLimitCPU</name>
 <description>Apache httpd alt süreçleri tarafından çalıştırılan süreçlerin
   işlemci tüketimine sınırlama getirir.</description>
 <syntax>RLimitCPU <var>saniye</var>|max [<var>saniye</var>|max]</syntax>
 <default>Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
 </default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>All</override>

 <usage>
     <p>1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
       sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
       birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
       izin verilen üst sınıra ayarlanacağını belirtmek üzere <code>max</code>
       olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
       <code>root</code> olarak veya sistem açılışı sırasında çalıştırılması
       gerekir.</p>

     <p>Bu sınırlar Apache httpd’nin kendi alt süreçlerine değil, isteklere
       yanıt verirken Apache httpd alt süreçlerinin çatalladıkları süreçlere
       uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir
       fakat borulu günlük kaydı gibi ana Apache httpd süreci tarafından
       çatallanmış süreçler olmazlar.</p>

     <p>İşlemci özkaynak sınırları saniye cinsinden ifade edilir.</p>
 </usage>
 <seealso><directive module="core">RLimitMEM</directive></seealso>
 <seealso><directive module="core">RLimitNPROC</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>RLimitMEM</name>
 <description>Apache httpd alt süreçleri tarafından çalıştırılan süreçlerin
   bellek tüketimine sınırlama getirir.</description>
 <syntax>RLimitMEM <var>bayt-sayısı</var>|max [<var>bayt-sayısı</var>|max]
 </syntax>
 <default>Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
 </default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>All</override>

 <usage>
     <p>1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
       sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
       birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
       izin verilen üst sınıra ayarlanacağını belirtmek üzere <code>max</code>
       olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
       <code>root</code> olarak veya sistem açılışı sırasında çalıştırılması
       gerekir.</p>

     <p>Bu sınırlar Apache httpd’nin kendi alt süreçlerine değil, isteklere
       yanıt verirken Apache httpd alt süreçlerinin çatalladıkları süreçlere
       uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir
       fakat borulu günlük kaydı gibi ana Apache httpd süreci tarafından
       çatallanmış süreçler olmazlar.</p>

     <p>Bellek özkaynak sınırları süreç başına bayt sayısı olarak ifade edilir.
     </p>
 </usage>
 <seealso><directive module="core">RLimitCPU</directive></seealso>
 <seealso><directive module="core">RLimitNPROC</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>RLimitNPROC</name>
 <description>Apache httpd alt süreçleri tarafından çalıştırılabilecek süreç
   sayısına sınırlama getirir.</description>
 <syntax>RLimitNPROC <var>sayı</var>|max [<var>sayı</var>|max]</syntax>
 <default>Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır
 </default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>All</override>

 <usage>
     <p>1 veya 2 değer alır. İlk değer bütün süreçler için sanal özkaynak
       sınırını, ikinci değer ise kesin özkaynak sınırını belirler. İki değer de
       birer sayı olabileceği gibi bu sınırın işletim sistemi yapılandırmasında
       izin verilen üst sınıra ayarlanacağını belirtmek üzere <code>max</code>
       olabilir. Kesin özkaynak sınırını yükseltmek için sunucunun
       <code>root</code> olarak veya sistem açılışı sırasında çalıştırılması
       gerekir.</p>

     <p>Bu sınırlar Apache httpd’nin kendi alt süreçlerine değil, isteklere
       yanıt verirken Apache httpd alt süreçlerinin çatalladıkları süreçlere
       uygulanır. Bunlar CGI betikleri ve SSI çalıştırma komutları olabilir
       fakat borulu günlük kaydı gibi ana Apache httpd süreci tarafından
       çatallanmış süreçler olmazlar.</p>

     <p>Süreç sayısı sınırı kullanıcı başına süreç sayısına sınırlama getirir.
     </p>

     <note><title>Ek Bilgi</title>
       <p>CGI süreçleri sunucu kullanıcı kimliğinden farklı bir kullanıcı
         kimliği altında çalışmıyorsa bu yönerge sunucunun kendi oluşturduğu
         süreç sayısını sınırlayacaktır. Bunun kanıtı <code>error_log</code>’da
         iletilerin çatallanamamasıdır.</p>
     </note>
 </usage>
 <seealso><directive module="core">RLimitMEM</directive></seealso>
 <seealso><directive module="core">RLimitCPU</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ScriptInterpreterSource</name>
 <description>CGI betikleri için yorumlayıcı belirleme tekniği</description>
 <syntax>ScriptInterpreterSource Registry|Registry-Strict|Script</syntax>
 <default>ScriptInterpreterSource Script</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context></contextlist>
 <override>FileInfo</override>
 <compatibility>Sadece Win32 için.</compatibility>

 <usage>
     <p>Bu yönerge Apache httpd’nin CGI betiklerini çalıştıracak yorumlayıcıyı
       nasıl tespit edeceğini belirler. <code>Script</code> öntanımlı olup
       Apache httpd’nin yorumlayıcı olarak betiğin diyezli ünlem satırında
       (<code>#!</code> ile başlayan ilk satır) belirtilen yorumlayıcıyı
       kullanacağını belirtir. Win32 sistemlerinde bu satır genellikle
       şöyledir:</p>

     <highlight language="perl">
 #!C:/Perl/bin/perl.exe
     </highlight>

     <p><code>perl</code> yorumlayıcının yeri <code>PATH</code> değişkeninde
       kayıtlı ise şöyle de olabilir:</p>

     <highlight language="perl">
 #!perl
     </highlight>

     <p><code>ScriptInterpreterSource Registry</code> değeri ise betik dosyası
       uzantısının (<code>.pl</code> gibi) Windows Sicili içindeki
       <code>HKEY_CLASSES_ROOT</code> ağacında arama yapmak için bir arama
       anahtarı olarak kullanılmasını sağlar. Betik dosyasını çalıştırmak için
       tanımlanmış komutu bulmak için <code>Shell\ExecCGI\Command</code> yoluna,
       orada yoksa <code>Shell\Open\Command</code> yoluna bakılır. İkisi de
       yoksa son çare olarak <code>Script</code> seçeneğinin davranışına
       dönülür.</p>

     <note type="warning"><title>Güvenlik</title>
     <p><directive module="mod_alias">ScriptAlias</directive>’lı dizinlerde
       Apache httpd bulduğu <strong>her</strong> dosyayı çalıştırmayı deneyeceğinden
       <code>ScriptInterpreterSource Registry</code> yapılandırmasını
       kullanırken dikkatli olun. <code>Registry</code> seçeneği genellikle
       çalıştırılmayacak dosyalar için istenmeyen program çağrılarına sebep
       olabilir. Örneğin, çoğu Windows sisteminde <code>.htm</code> dosyaları
       için ön tanımlı "open" komutu Microsoft Internet Explorer’ın
       çalıştırılmasına sebep olur; bu bakımdan, betik dizininde bulunan bir
       <code>.htm</code> dosyası için yapılan bir HTTP isteği tarayıcının sunucu
       artalanında çalıştırılmasına sebep olacaktır. Bu, sistemi bir kaç dakika
       içinde çökertmek için iyi bir yoldur.</p>
     </note>

     <p><code>Registry-Strict</code> seçeneği Apache HTTP Sunucusunun 2.0
       sürümünde yeni olup <code>Registry</code> seçeneğinin yaptığını
       <code>Shell\ExecCGI\Command</code> yolu için yapar. <code>ExecCGI</code>
       sistem tarafından bilinen bir anahtar olmadığından Windows Siciline elle
       kaydedilmesi gerekir ve dolayısıyla sisteminiz üzerinde istenmeyen
       program çağrılarına sebep olmaz.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>SeeRequestTail</name>
 <description>İsteğin 63 karakterden büyük olduğu varsayımıyla, mod_status'un
   ilk 63 karakteri mi yoksa son 63 karakteri mi göstereceğini
   belirler.</description>
 <syntax>SeeRequestTail On|Off</syntax>
 <default>SeeRequestTail Off</default>
 <contextlist><context>server config</context></contextlist>
 <compatibility>Apache httpd 2.2.7 ve sonrasında kullanılabilmektedir.
 </compatibility>

 <usage>
     <p><module>mod_status</module> modülü <code>ExtendedStatus On</code>
       ile işleme alınan asıl isteği gösterir. Tarihsel amaçlarla, isteğin
       sadece 63 karakteri gösterme amacıyla saklanır. Bu yönerge ilk 63
       karakterin mi (önceki davranış ve öntanımlı durum) yoksa son 63
       karakterin mi saklanacağını belirler. Bu, şüphesiz, isteğin uzunluğu 64
       karakter veya daha fazlaysa uygulanabilirdir.</p>

     <p>Apache httpd'ye gelen istek <code
     >GET&nbsp;/disk1/storage/apache/htdocs/images/imagestore1/food/apples.jpg&nbsp;HTTP/1.1</code>
     ise <module>mod_status</module> şunu gösterir:</p>

     <table border="1">
       <tr>
         <th>Off (öntanımlı)</th>
         <td>GET&nbsp;/disk1/storage/apache/htdocs/images/imagestore1/food/apples</td>
       </tr>
       <tr>
         <th>On</th>
         <td>orage/apache/htdocs/images/imagestore1/food/apples.jpg&nbsp;HTTP/1.1</td>
       </tr>
     </table>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerAdmin</name>
 <description>Sunucunun hata iletilerinde istemciye göstereceği eposta adresi
 </description>
 <syntax>ServerAdmin <var>eposta-adresi</var>|<var>URL</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>ServerAdmin</directive> yönergesi, sunucunun bir hata
       durumunda istemciye döndüreceği hata iletilerinde içereceği iletişim
       adresini belirtmek için kullanılır. Eğer <program>httpd</program>
       sağlanan değerin bir URL olmadığını saptarsa değerin bir eposta adresi
       olduğuna hükmeder ve önüne <code>mailto:</code> getirerek onu bir hiper
       bağ hedefi olarak kullanır. Çoğu CGI betiği bir eposta adresi
       belirtildiği kabulünü yaptığından değer olarak bir URL değil bir eposta
       adresi belirtmeniz önerilir. Eğer bir URL belirtecekseniz hedef sizin
       denetiminizde olan başka bir sunucuda bulunmalıdır, yoksa kullanıcılar
       hata durumunda bu adrese erişemeyebilirler.</p>

     <p>Kullanıcıların sunucu hakkında konuşurken isminizden bahsetmemeleri için
       burada belirtilecek adresin sırf bu işe adanmış bir adres olması daha
       iyidir. Örnek:</p>

     <highlight language="config">
 ServerAdmin www-admin@foo.example.com
     </highlight>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerAlias</name>
 <description>İstekleri isme dayalı sanal konaklarla eşleştirilirken
 kullanılacak konak adları için başka isimler belirtebilmeyi sağlar.
 </description>
 <syntax>ServerAlias <var>konakadı</var> [<var>konakadı</var>] ...</syntax>
 <contextlist><context>virtual host</context></contextlist>

 <usage>
     <p><directive>ServerAlias</directive> yönergesi, istekleri <a
       href="../vhosts/name-based.html">isme dayalı sanal konaklarla</a>
       eşleştirilirken kullanılacak konak adları için başka isimler
       belirtebilmeyi sağlar. <directive>ServerAlias</directive> dosya adı kalıp
       karakterleri içerebilir.</p>

     <highlight language="config">
 &lt;VirtualHost *:80&gt;
   ServerName server.example.com
   ServerAlias server server2.example.com server2
   ServerAlias *.example.com
   UseCanonicalName Off
   # ...
 &lt;/VirtualHost&gt;
     </highlight>

     <p>İsme dayalı sanal konaklardan en iyi eşleşme kümesinde olanlar
       yapılandırmada göründükleri sıraya göre işleme sokulur. Joker
       kullanımları arasında fark gözetilmeksizin <directive module="core"
       >ServerName</directive> veya <directive module="core"
       >ServerAlias</directive> yönergesi eşleşen ilk sanal konak
       kullanılır.</p>

     <p><directive type="section" module="core">VirtualHost</directive>
       bölümü içindeki isimlerin sırası (jokersiz)
       <directive>ServerAlias</directive> yönergesindeki gibi ele
       alınır.</p>

 </usage>
 <seealso><directive module="core">UseCanonicalName</directive></seealso>
 <seealso><a href="../vhosts/">Apache HTTP Sunucusu Sanal Konak Belgeleri</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerName</name>
 <description>Sunucunun özdeşleşeceği konak ismi ve port.</description>
 <syntax>ServerName [<var>şema</var>://]<var>alan-adı</var>|<var>ip-adresi</var>[:<var>port</var>]
 </syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>ServerName</directive> yönergesi, sunucunun kendini
       betimlemekte kullanacağı şema, konak adı ve port değerlerini belirler.
     </p>

     <p><a href="../vhosts/name-based.html">isme dayalı sanal
       konaklar</a> kullanılırken bir sanal konağı eşsiz bir şekilde betimlemek
       için <directive>ServerName</directive> kullanılır (muhtemelen
       <directive module="core">ServerAlias</directive> ile birlikte).</p>

     <p>Ek olarak, <directive module="core">UseCanonicalName</directive>
       yönergesine öntanımlı olmayan bir değer atanarak özüne yönlendiren
       URL'ler oluştururken de bu yönerge kullanılır.</p>

     <p>Örneğin, HTTP
       sunucusunun barındırıldığı makinenin ismi <code>mail.example.com</code>
       olduğu halde makinenin bir de <code>www.example.com</code> diye bir de
       DNS rumuzu varsa ve HTTP sunucunuzun bu rumuzla kendini
       özdeşleştirmesini isterseniz bunu şöyle belirtebilirsiniz:</p>

     <highlight language="config">
 ServerName www.example.com
     </highlight>

     <p><directive>ServerName</directive> yönergesi sunucu tanımının içinde
       herhangi bir yerde görünebilirse de her göründüğü yerde bir öncekini
       iptal eder.</p>

     <p>Bir <directive>ServerName</directive> ataması yapılmamışsa sunucu
       istemciye görünen sunucu ismini anlamak için önce işletim sistemine
       sistemin konak adını sorar. Bu başarılı olmazsa sistem üzerinde IP
       adresine bir ters DNS sorgusu yapar.</p>

     <p><directive>ServerName</directive> yönergesinde bir port belirtilmediği
       takdirde sunucu, isteğin geldiği portu kullanacaktır. Öngörülebilirlik ve
       güvenilirlik açısından en iyisi <directive>ServerName</directive>
       yönergesini kullanarak açıkça bir konak ismi ve port belirtmektir.</p>

     <p><a href="../vhosts/name-based.html">İsme dayalı sanal konaklar</a>
       kullanıyorsanız, <directive type="section" module="core"
       >VirtualHost</directive> bölümü içindeki
       <directive>ServerName</directive> yönergesi, isteğin <code>Host:</code>
       başlığında bu sanal konakla eşleşecek konak ismini belirler.</p>


     <p>Bazen sunucu, bir ters vekil, yük dengeleyici veya SSL yük aktarım
       uygulaması gibi bir aygıtın arkasında çalışır. Böyle durumlarda sunucunun
       kendine yönelik URL’leri doğru üretebildiğinden emin olmak için
       <directive>ServerName</directive> yönergesinde istemcinin bağlanacağı
       <code>https://</code> şeması ve port numarası belirtilir.</p>

     <p>Sunucunun kendine yönelik URL’lerin belirtilen portu içerip içermediğini
       veya istemcinin yaptığı istekte belirtilen port numarasının verilip
       verilmediğinin saptamasını sağlayan (örneğin, <module>mod_dir</module>
       modülü tarafından) ayarlar için <directive
       module="core">UseCanonicalName</directive> ve
       <directive module="core">UseCanonicalPhysicalPort</directive>
       yönergelerinin açıklamalarına bakınız.</p>

     <note type="warning">
     <p><directive>ServerName</directive> yönergesine isim atamadaki bir
       başarısızlık, sunucu başlatılırken isim bir IP adresine
       çözümlenebileceğinden bir uyarı çıktılanmasına sebep olur.
       <code>httpd</code> böyle bir durumda sistemin <code>hostname</code>
       komutunu kullanarak saptadığı konak ismini kullanacaktır. Bu konak ismi
       hemen hemen daima sizin istediğiniz isim olmayacaktır.</p>
     <example>
     httpd: Could not reliably determine the server's fully qualified domain name, using belgeler.yerel for ServerName
     </example>
     <p>Çevirisi: Sunucunun tamamen nitelenmiş alan adı gerektiği gibi
       saptanamadı, ServerName için belgeler.yerel kullanılıyor</p>
     </note>
 </usage>

 <seealso><a href="../dns-caveats.html">DNS ile ilgili konular ve Apache HTTP
     Sunucusu</a></seealso>
 <seealso><a href="../vhosts/">Apache HTTP Sunucusu Sanal Konak Belgeleri</a>
 </seealso>
 <seealso><directive module="core">UseCanonicalName</directive></seealso>
 <seealso><directive module="core">UseCanonicalPhysicalPort</directive></seealso>
 <seealso><directive module="core">ServerAlias</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerPath</name>
 <description>Uyumsuz bir tarayıcı tarafından erişilmesi için bir isme dayalı sanal konak için meşru URL yolu</description>
 <syntax>ServerPath <var>URL-yolu</var></syntax>
 <contextlist><context>virtual host</context></contextlist>

 <usage>
     <p><directive>ServerPath</directive> yönergesi <a href="../vhosts/">isme
       dayalı sanal konaklar</a>da kullanmak için konağa meşru bir URL yolu
       belirler.</p>
 </usage>
 <seealso><a href="../vhosts/">Apache HTTP Sunucusu Sanal Konak Belgeleri</a>
 </seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerRoot</name>
 <description>Sunucu yapılandırması için kök dizin</description>
 <syntax>ServerRoot <var>dizin-yolu</var></syntax>
 <default>ServerRoot /usr/local/apache</default>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p><directive>ServerRoot</directive> yönergesi sunucu yapılandırmasını
       içeren dizinin yerini belirtir. Genellikle <code>conf/</code> ve
       <code>logs/</code> gibi alt dizinler içerir. <directive
       module="core">Include</directive>, <directive
       module="mod_so">LoadModule</directive> gibi diğer yapılandırma
       yönergelerindeki göreli yollar bu dizine göre ele alınır.</p>

     <highlight language="config">
 ServerRoot "/home/httpd"
     </highlight>

     <p><directive>ServerRoot</directive> için öntanımlı yer <a
       href="../programs/configure.html"><code>configure</code></a> betiğinin
       <code>--prefix</code> seçeneği ile değiştirilebilir ve sunucunun çoğu
       üçüncü parti dağıtıcısı öntanımlı yeri yukardakilerden farklı bir yere
       ayarlar.</p>

 </usage>
 <seealso><a href="../invoking.html"><code>httpd</code> için <code>-d</code> seçeneği</a></seealso>
 <seealso><directive>ServerRoot</directive> dizininin erişim izinlerinin nasıl
   ayarlanması gerektiğini öğrenmek için <a
   href="../misc/security_tips.html#serverroot">güvenlik ipuçları</a></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerSignature</name>
 <description>Sunucu tarafından üretilen belgelerin dipnotunu ayarlar.
 </description>
 <syntax>ServerSignature On|Off|EMail</syntax>
 <default>ServerSignature Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>All</override>

 <usage>
     <p><directive>ServerSignature</directive> yönergesi, sunucu tarafından
       üretilen belgelerin (hata iletileri, <module>mod_proxy</module> ftp dizin
       listeleri, <module>mod_info</module> çıktısı, vs.) altındaki dipnot
       satırını yapılandırabilmenizi sağlar. Böyle bir dipnot satırın
       istenmesinin sebebi vekil zincirlerinde istemciye dönen hata iletisinin
       aslında hangi sunucu tarafından üretildiğini kullanıcıya bildirmektir.</p>

     <p><code>Off</code> değeri öntanımlı değer olup dipnot satırının
       gösterilmemesini sağlar (Apache-1.2 ve öncesi ile uyumluluk).
       <code>On</code> değeri, sunucu sürüm numarası ve hizmeti sunan sanal
       konağın isminden (<directive module="core">ServerName</directive>) oluşan
       bir dipnot satırı oluşturulmasını sağlar; <code>EMail</code> değeri bu
       ikisine ek olarak satıra <directive module="core">ServerAdmin</directive>
       ile belirtilen adres için bir "mailto:" bağı ekler.</p>

     <p>2.0.44 sürümünden beri sunucu sürüm numarasının ayrıntıları <directive
       module="core">ServerTokens</directive> yönergesi ile belirlenmektedir.</p>
 </usage>
 <seealso><directive module="core">ServerTokens</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>ServerTokens</name>
 <description><code>Server</code> HTTP yanıt başlığını yapılandırır.
 </description>
 <syntax>ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full</syntax>
 <default>ServerTokens Full</default>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p>Bu yönerge <code>Server</code> HTTP yanıt başlığı alanında istemcilere
       sunucunun işletim sistemi, sunucuyla derlenmiş modüller, vs. hakkında
       bilgi verilip verilmeyeceğini belirler.</p>

     <dl>
       <dt><code>ServerTokens Full</code> (veya belirtilmezse)</dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server: Apache/2.4.2
         (Unix) PHP/4.2.2 MyMod/1.2</code></dd>

       <dt><code>ServerTokens Prod[uctOnly]</code></dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server:
       Apache</code></dd>

       <dt><code>ServerTokens Major</code></dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server:
       Apache/2</code></dd>

       <dt><code>ServerTokens Minor</code></dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server:
       Apache/2.4</code></dd>

       <dt><code>ServerTokens Min[imal]</code></dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server:
       Apache/2.4.2</code></dd>

       <dt><code>ServerTokens OS</code></dt>
       <dd>Sunucu şunu gönderir (<em>örnek</em>): <code>Server: Apache/2.4.2
       (Unix)</code></dd>

     </dl>

     <p>Bu ayarlama sunucunun tamamını etkiler ve her sanal konak için
       farklılaştırılamaz.</p>

     <p>2.0.44 sürümünden itibaren bu yönerge <directive
       module="core">ServerSignature</directive> yönergesi tarafından sunulan
       bilgiyi de etkilemektedir.</p>

     <note><directive>ServerTokens</directive> yönergesinde
     <code>minimal</code>'den azının belirtilmesi önerilmez. Bunun sebebi ara
     işlemlerle ilgili hata ayıklamasını zorlaştırmasıdır. Ayrıca,
     <code>Server:</code> başlığının iptal edilmesinin sunucunuzu daha güvenli
     yapmayacağına dikkat ediniz; "çapraşıklıkla sağlanan güvenlik" düşüncesi
     gerçekle bağdaşmaz ve güvenliği olumsuz etkiler.</note>

 </usage>
 <seealso><directive module="core">ServerSignature</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>SetHandler</name>
 <description>Eşleşen tüm dosyaların belli bir eylemci tarafından işlenmesine
 sebep olur.</description>
 <syntax>SetHandler <var>eylemci-ismi</var>|none|<var>ifade</var></syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>ifade seçeneği 2.4.19 sürümünde eklendi</compatibility>

 <usage>
     <p>Bir <code>.htaccess</code> dosyasına veya bir <directive type="section"
       module="core">Directory</directive> ya da <directive type="section"
       module="core">Location</directive> bölümüne yerleştirildiğinde, eşleşen
       tüm dosyaların, ismi <var>eylemci-ismi</var> ile belirtilen <a
       href="../handler.html">eylemci</a> tarafından çözümlenmesine sebep olur.
       Örneğin, bir dizin içindeki bütün dosyaların, uzantılarına bakılmaksızın
       birer imagemap kural dosyası olarak çözümlenmesini istersiniz, bu dizin
       içindeki bir <code>.htaccess</code> dosyasına şöyle bir satır
       koyabilirsiniz:</p>

     <highlight language="config">
 SetHandler imap-file
     </highlight>

     <p>Başka bir örnek: <code>http://localhost/status</code> gibi bir istek
       yapıldığında sunucunun bir durum bilgisi göstermesi için
       <code>httpd.conf</code> dosyasına şöyle bir satır koyabilirsiniz:</p>

     <highlight language="config">
 &lt;Location "/status"&gt;
   SetHandler server-status
 &lt;/Location&gt;
     </highlight>

     <p>Bu yönergeyi ayrıca, belli bir dosya uzantısına sahip dosyalara uygun
       bir eylemci atamak için de kullanabilirsiniz. örnek:</p>

     <highlight language="config">
 &lt;FilesMatch "\.php$"&gt;
     SetHandler application/x-httpd-php
 &lt;/FilesMatch&gt;
     </highlight>

     <p>Dizge değerli ifadeler istek öncesi değişkenleri içerecek şekilde
       düzenlenebilir. Buna ismli düzenli ifadelere yapılan geriye başvurular
       dahildir:</p>

     <highlight language="config">
 &lt;LocationMatch ^/app/(?&lt;sub&gt;[^/]+)/&gt;
      SetHandler "proxy:unix:/var/run/app_%{env:MATCH_sub}.sock|fcgi://localhost:8080"
 &lt;/LocationMatch&gt;
     </highlight>

      <p>Evvelce tanımlanmış bir <directive>SetHandler</directive> yönergesini
       <code>None</code> değeriyle geçersiz hale getirebilirsiniz.</p>

     <note><title>Bilgi</title>
     <p><directive>SetHandler</directive> yönergesi,
       öntanımlı eylemcileri geçersiz kıldığından, index dosyaları ve dizinleri
       belirtmek için URL’nin sonuna bölü çizgisi (/) getirmek şeklindeki
       normal davranış baskılanır.</p>
     </note>
 </usage>

 <seealso><directive module="mod_mime">AddHandler</directive></seealso>

 </directivesynopsis>

 <directivesynopsis>
 <name>SetInputFilter</name>
 <description>POST girdilerini ve istemci isteklerini işleyecek süzgeçleri
 belirler.</description>
 <syntax>SetInputFilter <var>süzgeç</var>[;<var>süzgeç</var>...]</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>

 <usage>
     <p><directive>SetInputFilter</directive> yönergesi, istemci isteklerini
       ve sunucu tarafından alındığı takdirde POST girdisini işleyecek süzgeç
       veya süzgeçleri belirler. Bu, diğer <directive module="mod_mime"
       >AddInputFilter</directive> yönergeleri dahil evvelce tanımlanmış
       süzgeçlere eklenir.</p>

     <p>Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı
      virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak
      sıralanmalıdırlar.</p>
 </usage>
 <seealso><a href="../filter.html">Süzgeçler</a> belgesi</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>SetOutputFilter</name>
 <description>Sunucunun yanıtlarını işleyecek süzgeçleri belirler.</description>
 <syntax>SetOutputFilter <var>süzgeç</var>[;<var>süzgeç</var>...]</syntax>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context><context>.htaccess</context>
 </contextlist>
 <override>FileInfo</override>

 <usage>
     <p><directive>SetOutputFilter</directive> yönergesi, istemciye
      gönderilmeden önce sunucunun yanıtlarını işleyecek süzgeçleri belirler.
      Bu, diğer <directive module="mod_mime">AddOutputFilter</directive>
      yönergeleri dahil evvelce tanımlanmış süzgeçlere eklenir.</p>

     <p>Örneğin, aşağıdaki yapılandırma ile <code>/www/data/</code> dizinindeki
      bütün dosyalar sunucu taraflı içerik kapsamında ele alınacaktır.</p>

     <highlight language="config">
 &lt;Directory "/www/data/"&gt;
   SetOutputFilter INCLUDES
 &lt;/Directory&gt;
     </highlight>

     <p>Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı
      virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak
      sıralanmalıdırlar.</p>
 </usage>
 <seealso><a href="../filter.html">Süzgeçler</a> belgesi</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>TimeOut</name>
 <description>Bir istek için başarısız olmadan önce belirli olayların
 gerçekleşmesi için sunucunun geçmesini bekleyeceği süre.</description>
 <syntax>TimeOut <var>saniye</var></syntax>
 <default>TimeOut 60</default>
 <contextlist><context>server config</context><context>virtual host</context>
 </contextlist>

 <usage>
     <p><directive>TimeOut</directive> yönergesi Apache httpd’nin aşağıdaki
       durumlarda G/Ç için bekleyeceği süreyi belirler:</p>

     <ul>
       <li><p>Veriyi istemciden okurken, okuma tamponu boş olduğu takdirde bir
         TCP paketinin gelmesini bekleyeceği süre.</p>
       <p>Yeni bir bağlantıda ilk veri için, sunucuya yeni bağlantıyı aktaran
         bir <directive module="core">AcceptFilter</directive> yönergesi ile
         ilgili yapılandırma ele alınıncaya kadar bu yönerge etkilenmez.</p>
       </li>

       <li>Veriyi istemciye yazarken, gönderme tamponu dolu olduğu takdirde bir
         paket alındısı için beklenecek süre.</li>

       <li><module>mod_cgi</module> modülünde, bir CGI betiğinden çıktı için
         beklenecek süre.</li>

       <li><module>mod_ext_filter</module> modülünde, bir süzme işleminden çıktı
         almak için beklenecek süre.</li>

       <li><module>mod_proxy</module> modülünde, <directive
         module="mod_proxy">ProxyTimeout</directive> yönergesi
         yapılandırılmamışsa öntanımlı zaman aşımı değeri.</li>
     </ul>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>TraceEnable</name>
 <description><code>TRACE</code> isteklerinde davranış şeklini belirler
 </description>
 <syntax>TraceEnable <var>[on|off|extended]</var></syntax>
 <default>TraceEnable on</default>
 <contextlist><context>server config</context>
 <context>virtual host</context></contextlist>

 <usage>
     <p>Bu yönerge çekirdek ve vekil (<module>mod_proxy</module>) sunucuların
       her ikisi için öntanımlı <code>TRACE</code> davranışını değiştirir.
       Öntanımlı olan <code>TraceEnable on</code> ile RFC 2616’dan kaynaklanan
       ve isteğe herhangi bir istek gövdesinin eşlik etmesine izin vermeyen
       <code>TRACE</code> isteklerine izin verilir. <code>TraceEnable off</code>
       ile çekirdek ve vekil (<module>mod_proxy</module>) sunucuların her ikisi
       de <code>TRACE</code> isteklerine yanıt olarak bir <code>405</code>
       (Yönteme izin verilmiyor) hatası döndürür.</p>

     <p><code>TraceEnable extended</code> ile sadece sınama ve tanı koyma
       amaçlarına yönelik olarak istek gövdelerine izin verilir. Asıl sunucu
       istek gövdesini 64kB ile sınırlar (<code>Transfer-Encoding: chunked</code>
       kullanılmışsa bölüm başlıkları için 8kB daha). Asıl sunucu yanıt
       gövdesinde tüm başlıkları ve bölüm başlıklarının tamamını yansıtacaktır.
       Vekil sunucuda ise istek gövdesi için 64kB’lık sınır yoktur.</p>

     <note><title>Bilgi</title>
     <p>Aksine iddialara rağmen, <code>TRACE</code> yöntemini etkinleştirmek
       Apache httpd'de bir güvenlik açığı değildir. <code>TRACE</code> yöntemi
       HTTP/1.1 belirtiminde tanımlanmış olup desteklenmesi umulmuştur.</p>
     </note>

 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>UnDefine</name>
 <description>Bir değişkeni tanımsız yapar</description>
 <syntax>UnDefine <var>değişken-ismi</var></syntax>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p><directive module="core">Define</directive> yönergesinde veya
       <program>httpd</program>'nin <code>-D</code> seçeneğiyle belirtileni
       geri alır.</p>
     <p>Bu yönerge başlatma betiklerinde <code>-D</code> seçeneğinin argümanını
       değiştirmek gerekmeksizin <directive module="core" type="section"
       >IfDefine</directive> bölümlerinin kullanımını değiştirmek için
       kullanılabilir.</p>
     <p>Bu yönerge sanal konak bağlamında desteklenirken, kapsanan sanal
       konaklar haricinde, değişiklikleri kendisinden sonraki tüm yapılandırma
       yönergelerinde görünür kılar.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>UseCanonicalName</name>
 <description>Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
 </description>
 <syntax>UseCanonicalName On|Off|DNS</syntax>
 <default>UseCanonicalName Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context></contextlist>

 <usage>
     <p>Apache httpd‘nin çoğu durumda özüne yönelik URL‘ler (isteğin tekrar
       aynı sunucuya yapıldığı bir URL türü) oluşturması gerekir.
       <code>UseCanonicalName On</code> ile Apache httpd, sunucu için meşru
       ismi ve portu oluşturmak için
       <directive module="core">ServerName</directive>
       yönergesinde belirtilen ismi ve portu kullanır. Bu isim  CGI'lerde
       <code>SERVER_NAME</code> ve <code>SERVER_PORT</code> değerlerinde ve tüm
       özüne yönelik URL’lerde kullanılır.</p>

     <p><code>UseCanonicalName Off</code> ile Apache httpd, özüne yönelik URL’leri
       varsa istemci tarafından sağlanan konak ismini ve portu kullanarak
       oluşturur; bunlar istemci tarafından sağlanmamışsa yukarıda tanımlanan
       işleme başvurulur. Bu değerler, <a href="../vhosts/name-based.html">isme
       dayalı sanal konakları</a> gerçekleştirirken kullanılan değerlerle aynı
       olup aynı istemcilerle kullanılabilir. <code>SERVER_NAME</code> ve
       <code>SERVER_PORT</code> CGI değişkenleri de istemci tarafından sağlanan
       isim ve portla oluşturulur.</p>

     <p>Bir örnek olarak, iç ağdaki istemcilerin sunucuya <code>www</code> gibi
       bir kısa isim kullanarak bağlandığı durumu ele alırsak daha yararlı
       olur. Kullanıcılar bir kısa isim ve bir dizin isminden oluşan ve <em>bir
       / ile sonlandırılmamış</em> <code>http://www/splat</code> şeklinde bir
       istek yaparlarsa, Apache httpd onları
       <code>http://www.example.com/splat/</code> adresine yönlendirecektir.
       Eğer kimlik doğrulama da etkinse bu kullanıcının iki defa kimlik
       doğrulamasına sokulmasına sebep olacaktır (bir kere <code>www</code>
       için bir kere de <code>www.example.com</code> için; daha fazla bilgi için <a
       href="http://wiki.apache.org/httpd/FAQ#Why_does_Apache_ask_for_my_password_twice_before_serving_a_file.3F"
       >SSS</a>’ye bakınız). Fakat <directive>UseCanonicalName Off</directive>
       olsaydı Apache httpd isteği <code>http://www/splat/</code> adresine
       yönlendirecekti.</p>

     <p><code>UseCanonicalName DNS</code> diye üçüncü bir seçenek daha vardır ve
       istek yaparken <code>Host:</code> başlığını kullanmayan eski istemcileri
       desteklemek amacıyla IP’ye dayalı sanal konaklarla kullanmak için
       tasarlanmıştır. Bu seçenek etkin olduğunda Apache httpd, istemciyi özüne
       yönelik URL’lerle doğru yere bağlamak için sunucu IP adresi üzerinde bir
       ters DNS sorgusu yapar.</p>

     <note type="warning"><title>Uyarı</title>
     <p>Eğer CGI’ler <code>SERVER_NAME</code> değerleri için önkabuller
       yapıyorlarsa bu seçenek işlerinin bozulmasına yol açabilir. Aslında
       istemciler konak ismi olarak istedikleri değeri vermekte özgürdürler.
       Fakat eğer CGI, özüne yönelik URL’leri oluştururken sadece
       <code>SERVER_NAME</code> değerini kullanıyorsa bu istendiği gibi
       çalışacaktır.</p>
     </note>
 </usage>
 <seealso><directive module="core">UseCanonicalPhysicalPort</directive></seealso>
 <seealso><directive module="core">ServerName</directive></seealso>
 <seealso><directive module="mpm_common">Listen</directive></seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>UseCanonicalPhysicalPort</name>
 <description>Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
 </description>
 <syntax>UseCanonicalPhysicalPort On|Off</syntax>
 <default>UseCanonicalPhysicalPort Off</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context></contextlist>

 <usage>
     <p>Apache httpd‘nin çoğu durumda özüne yönelik URL‘ler (isteğin tekrar
       aynı sunucuya yapıldığı bir URL türü) oluşturması gerekir. Apache httpd
       <directive module="core">UseCanonicalName</directive> yönergesine bağlı
       olarak sunucu için meşru portu oluştururken
       <code>UseCanonicalPhysicalPort On</code> ile olası port olarak istek
       tarafından kullanılmakta olan fiziksel portu kullanacaktır.
       <code>UseCanonicalPhysicalPort Off</code> olduğunda ise geçerli bir port
       numarası oluşturmak için asıl fiziksel port yerine yapılandırma bilgisi
       kullanılır.</p>

     <note><title>Ek Bilgi</title>
     <p>Fiziksel port kullanımı etkin olduğunda işlemler şu sırayla
       yürütülür:</p>
      <dl>
      <dt><code>UseCanonicalName On</code></dt>
      <dd>
      <ol>
       <li><directive module="core">Servername</directive> ile sağlanan port
       </li>
       <li>Fiziksel port</li>
       <li>Öntanımlı port</li>
      </ol>
      </dd>
      <dt><code>UseCanonicalName Off | DNS</code></dt>
      <dd>
      <ol>
       <li><code>Host:</code> başlığından çözümlenen port</li>
       <li>Fiziksel port</li>
       <li><directive module="core">Servername</directive> yönergesinde
         belirtilen port</li>
       <li>Öntanımlı port</li>
      </ol>
      </dd>
      </dl>

     <p><code>UseCanonicalPhysicalPort Off</code> olduğunda işlem sırasında
       fiziksel port adımları atlanır.</p>
     </note>

 </usage>
 <seealso><directive module="core">UseCanonicalName</directive></seealso>
 <seealso><directive module="core">ServerName</directive></seealso>
 <seealso><directive module="mpm_common">Listen</directive></seealso>
 </directivesynopsis>

 <directivesynopsis type="section">
 <name>VirtualHost</name>
 <description>Sadece belli bir konak ismine ve porta uygulanacak yönergeleri barındırır.</description>
 <syntax>&lt;VirtualHost
     <var>adres</var>[:<var>port</var>] [<var>adres</var>[:<var>port</var>]]
     ...&gt; ... &lt;/VirtualHost&gt;</syntax>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p><directive type="section">VirtualHost</directive> ve
       <code>&lt;/VirtualHost&gt;</code> birlikte sadece belli bir sanal konağa
       uygulanacak yönergeleri sarmalamakta kullanılırlar. Bir sanal konak
       kapsamında belirtilebilecek her yönerge kullanılabilir. Sunucu belli bir
       sanal konak üzerindeki bir belge için bir istek aldığında <directive
       type="section">VirtualHost</directive> bölümünde bulunan yapılandırma
       yönergelerini kullanır. <var>adres</var> şunlardan biri olabilir,
       istemlik olarak ikinokta imi ve bir port numarası (veya *)
       eklenebilir:</p>

     <ul>
       <li>Sanal konağın IP adresi.</li>

       <li>Sanal konağın IP adresi için tam nitelenmiş alan adı (önerilmez).
       </li>

       <li>Tüm IP adresleri ile eşleşmek üzere <code>*</code> karakteri.</li>

       <li><code>*</code> için bir takma ad olarak <code>_default_</code>
         dizgesi.</li>
     </ul>

     <highlight language="config">
 &lt;VirtualHost 10.1.2.3:80&gt;
   ServerAdmin webmaster@host.example.com
   DocumentRoot "/www/docs/host.example.com"
   ServerName host.example.com
   ErrorLog "logs/host.example.com-error_log"
   TransferLog "logs/host.example.com-access_log"
 &lt;/VirtualHost&gt;
     </highlight>


     <p>İsteğe bağlı port numarasını belirtmeyi mümkün kılmak için IPv6
       adresleri köşeli ayraç içine alınır. IPv6 adresi kullanılan bir
       örnek:</p>

     <highlight language="config">
 &lt;VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80&gt;
   ServerAdmin webmaster@host.example.com
   DocumentRoot "/www/docs/host.example.com"
   ServerName host.example.com
   ErrorLog "logs/host.example.com-error_log"
   TransferLog "logs/host.example.com-access_log"
 &lt;/VirtualHost&gt;
     </highlight>

     <p>Her sanal konağın ya farklı bir IP adresi ve port ile ya da farklı bir
       konak ismiyle eşleşmesi gerekir. Birinci durumda sunucu makinesinin çok
       sayıda adresten IP paketleri kabul edecek şekilde yapılandırılması
       gerekir. (Eğer makinede çok sayıda ağ arabirimi yoksa bu, işletim sistemi
       desteklediği takdirde <code>ifconfig alias</code> komutuyla
       sağlanabilir.)</p>

     <note><title>Ek Bilgi</title>
     <p><directive type="section">VirtualHost</directive> kullanımı Apache
       httpd’nin dinleyeceği adresler üzerinde belirleyici değildir. Apache
       httpd’nin doğru adresi dinlediğinden emin olmak için <directive
       module="mpm_common">Listen</directive> kullanmanız gerekebilir.</p>
     </note>

     <p>Her <directive type="section">VirtualHost</directive> bloku içinde bir
       <directive module="core">ServerName</directive> yönergesi mutlaka
       olmalıdır. Yokluğu halinde "ana" sunucu yapılandırmasındaki <directive
       module="core">ServerName</directive> miras alınacaktır.</p>

     <p>Bir istek alındığında, sunucu isteği, sadece yerel IP adresi ve port
       çiftine dayalı en iyi eşleşen ilk <directive type="section"
       >VirtualHost</directive> bölümüne eşler. Joker kullanmayanlar daha
       yüksek önceliğe sahiptir. IP ve port çiftine dayalı bir eşleşme
       bulunamazsa istek için ana sunucu yapılandırması kullanılır.</p>

     <p>En iyi eşleşen IP adresi ve port çiftini birden fazla sanal konak
       kullanıyorsa sunucu bu sanal konaklar (liste) arasından istenen konak
       ismiyle en iyi eşleşeni seçer. Eşleşen hiçbir isme dayalı sanal konak
       yoksa listedeki IP adresi ile eşleşen ilk sanal konak kullanılır. Bunun
       sonucu olarak, belirtilen IP adresi ve port çifti için listedeki ilk
       sanal konak, bu IP adresi ve port çifti için öntanımlı sanal
       konaktır.</p>

     <note type="warning"><title>Güvenlik</title>
     <p>Günlük dosyalarının sunucuyu çalıştıran kullanıcıdan başka herkes
       tarafından yazılabilen bir yerde saklanmasından dolayı ortaya çıkabilecek
       güvenlik sorunları hakkında daha ayrıntılı bilgi için <a
       href="../misc/security_tips.html">güvenlik ipuçları</a> belgesine
       bakınız.</p>
     </note>
 </usage>
 <seealso><a href="../vhosts/">Apache HTTP Sunucusu Sanal Konak Belgeleri</a>
 </seealso>
 <seealso><a href="../dns-caveats.html">DNS ile İlgili Konular ve Apache HTTP
     Sunucusu</a></seealso>
 <seealso><a href="../bind.html">Apache HTTP Sunucusunun belli adresleri ve
     portları dinlemek üzere yapılandırılması</a></seealso>
 <seealso>Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir
   arada ele alındığının açıklaması için <a href="../sections.html">
   &lt;Directory&gt;, &lt;Location&gt; ve &lt;Files&gt; bölümleri nasıl
   çalışır?</a> belgesine bakınız.</seealso>
 </directivesynopsis>

 <directivesynopsis>
 <name>MergeTrailers</name>
 <description>Trailer alanlarının başlığa dahil edilip edilmeyeceğini belirler</description>
 <syntax>MergeTrailers [on|off]</syntax>
 <default>MergeTrailers off</default>
 <contextlist><context>server config</context><context>virtual host</context></contextlist>
 <compatibility>2.4.11 ve sonrası</compatibility>

 <usage>
     <p>Bu yönerge HTTP Trailer alanlarının dahili HTTP başlıklarına kopyalanıp
       kopyalanmayacağını belirler. Kopyalama işlemi istek gövdesi tamamen
       alındığında gerçekleşir, çoğu başlık işleminin çok sonra istek
       başlıklarını inceleme veya değiştirme şansı olur.</p>
     <p>Bu seçenek, Trailer alanlarını daima kopyalayan 2.4.11 öncesi
       dağıtımlarla uyumluluk için vardır.</p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>QualifyRedirectURL</name>
 <description>REDIRECT_URL ortam değişkeninin tamamen nitelenmiş olup
 olmayacağını denetler</description>
 <syntax>QualifyRedirectURL ON|OFF</syntax>
 <default>QualifyRedirectURL OFF</default>
 <contextlist><context>server config</context><context>virtual host</context>
 <context>directory</context>
 </contextlist>
 <override>FileInfo</override>
 <compatibility>Yönerge 2.4.18 ve sonrasında desteklenmektedir. 2.4.17
 sürümünde 'QualifyRedirectURL ON' yapılandırması mevcutmuş gibi
 davranılır.</compatibility>

 <usage>
     <p>Bu yönerge sunucuya REDIRECT_URL ortam değişkenin tamamen nitelenmiş
       olacağını temin eder. Değişken öntanımlı olarak istemci tarafından talep
       edilen URL'yi harfi harfine içerir, "/index.html" gibi.
       <directive module="core">QualifyRedirectURL ON</directive> belirtilseydi
       aynı istek "http://www.example.com/index.html" gibi bir değerle
       sonuçlanırdı.</p>

      <p>Böyle belirtilmemiş olsa bile, istek tam nitelenmiş bir URL
        içerseydi REDIRECT_URL de tam nitelenmiş URL'yi içerirdi.
     </p>
 </usage>
 </directivesynopsis>

 <directivesynopsis>
 <name>RegisterHttpMethod</name>
 <description>Standart olamayan HTTP yöntemlerini belirler</description>
 <syntax>RegisterHttpMethod <var>yöntem</var> [<var>yöntem</var> [...]]</syntax>
 <contextlist><context>server config</context></contextlist>

 <usage>
     <p>İlgili RFClerle uyumlu olmayan HTTP Yöntemleri Apache HTTPD'de isteğin
       işlenmesi sırasında  normal olarak reddedilir. Bundan kaçınmak için, uyumsuz
       HTTP yöntemlerini modüller destekli hale getirebilir.
       <directive>RegisterHttpMethod</directive> yönergesi böyle yöntemleri elle
       desteklenir yapmaya yarar. Bu tür yöntemler CGI gibi harici işlemlere
       aktarılıyorsa bu işlem yararlıdır.</p>
 </usage>
 </directivesynopsis>

 </modulesynopsis>