<?xml version="1.0"?>

<!DOCTYPE modulesynopsis SYSTEM "/style/modulesynopsis.dtd">

<?xml-stylesheet type="text/xsl" href="/style/manual.tr.xsl"?>

<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>

<compatibility>Windows'ta Apache httpd 2.3.3 ve sonrasında diğerlerinde Apache

httpd 2.1.5 ve sonrasında mevcuttur.</compatibility>

<usage>

<p>Bu yönerge <directive>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>

<example>AcceptFilter nntp none</example>

<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>

<example>

AcceptFilter http httpready <br/>

AcceptFilter https dataready

</example>

<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>

<example>

AcceptFilter http data <br/>

AcceptFilter https data

</example>

<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://homepages.cwi.nl/~aeb/linux/man2html/man7/tcp.7.html"

>tcp(7)</a> kılavuz sayfasına bakınız.</p>

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

<example>

AcceptFilter http data <br/>

AcceptFilter https data

</example>

<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. Windows

<code>AcceptEx()</code> arayüzünü tetikleyen iki değer vardır ve ağ

soketlerini bağlantılar arasında yer değiştirirler. <code>data</code>,

veri aktarılana kadar yukarıda anlatıldığı gibi bekler ve ilk veri

tamponu ve uç ağ adresleri tek bir <code>AcceptEx()</code> çağrısından

alınır. <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>

</usage>

<seealso><directive>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>

<compatibility>Apache httpd 2.0.30 ve sonrasında mevcuttur.</compatibility>

<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>

<example>

&lt;Files "mypaths.shtml"&gt;<br />

<indent>

Options +Includes<br />

SetOutputFilter INCLUDES<br />

AcceptPathInfo On<br />

</indent>

&lt;/Files&gt;

</example>

</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>

<example>

AccessFileName .acl

</example>

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

önce,</p>

<example>

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

<indent>

AllowOverride None<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example>

AddDefaultCharset utf-8

</example>

<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>Apache httpd 2.0.46 ve sonrasında mevcuttur. 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 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

(boşluksuz) 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>

</dd>

</dl>

<p>Örnek:</p>

<example>

AllowOverride AuthConfig Indexes

</example>

<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>

<example>

AllowOverride None<br />

AllowOverrideList Redirect RedirectMatch

</example>

<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>

<example>

AllowOverride AuthConfig<br />

AllowOverrideList CookieTracking CookieName

</example>

<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>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>

<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>

<example><title>Example</title>

DefaultRuntimeDir scratch/

</example>

<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>

<example>

DefaultType none

</example>

<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>

<example>

&lt;IfDefine TEST&gt;<br/>

&nbsp;&nbsp;Define servername test.example.com<br/>

&lt;/IfDefine&gt;<br/>

&lt;IfDefine !TEST&gt;<br/>

&nbsp;&nbsp;Define servername www.example.com<br/>

&nbsp;&nbsp;Define SSL<br/>

&lt;/IfDefine&gt;<br/>

</example>

<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>

</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>

<example>

&lt;Directory /usr/local/httpd/htdocs&gt;<br />

<indent>

Options Indexes FollowSymLinks<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example>

&lt;Directory ~ "^/www/.*/[0-9]{3}"&gt;

</example>

<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>

<example>

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

<indent>

AllowOverride None<br />

</indent>

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

<br />

&lt;Directory /home&gt;<br />

<indent>

AllowOverride FileInfo<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example>

&lt;Directory ~ abc$&gt;<br />

<indent>

# ... yönergeler burada ...<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example>

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

<indent>

Order Deny,Allow<br />

Deny from All<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example>

&lt;DirectoryMatch "^/www/(.+/)?[0-9]{3}"&gt;

</example>

<p>yönergesi <code>/www/</code> içindeki üç 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>

</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>

<example>

DocumentRoot /usr/web

</example>

<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>

<example>

&lt;If "-z req('Host')"&gt;<br/>

...<br/>

&lt;/If&gt;<br/>

&lt;Else&gt;<br/>

...<br/>

&lt;/Else&gt;<br/>

</example>

<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>

<example>

&lt;If "-R '10.1.0.0/16'"&gt;<br/>

...<br/>

&lt;/If&gt;<br/>

&lt;ElseIf "-R '10.0.0.0/8'"&gt;<br/>

...<br/>

&lt;/ElseIf&gt;<br/>

&lt;Else&gt;<br/>

...<br/>

&lt;/Else&gt;<br/>

</example>

<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>

<example>

EnableMMAP Off

</example>

<p>Bu özellik, sadece NFS dosya sistemi üzerinde sunulan dosyaları

kapsamak üzere şu şekilde kolayca kapatılabilir:</p>

<example>

&lt;Directory "/nfs-dosya-yolu"&gt;

<indent>

EnableMMAP Off

</indent>

&lt;/Directory&gt;

</example>

</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>2.0.44 ve sonrasında mevcuttur. Ö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>

<example>

EnableSendfile On

</example>

<p>Bu özellik, sadece bir ağ dosya sistemi üzerinde sunulan

dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:</p>

<example>

&lt;Directory "/path-to-nfs-files"&gt;

<indent>

EnableSendfile Off

</indent>

&lt;/Directory&gt;

</example>

<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>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>

<example><title>Örnek</title>

# mod_include yüklü değilse bilelim<br />

&lt;IfModule !include_module&gt;<br />

Hata: mod_include mod_foo için gerekiyor. LoadModule ile yükleyin.<br />

&lt;/IfModule&gt;<br />

<br />

# SSL veya NOSSL tanımlı mı bilelim<br />

&lt;IfDefine SSL&gt;<br />

&lt;IfDefine NOSSL&gt;<br />

Hata: Ne SSL ne de NOSSL tanımlı. Sadece biri tanımlı olsa yeter.<br />

&lt;/IfDefine&gt;<br />

&lt;/IfDefine&gt;<br />

&lt;IfDefine !SSL&gt;<br />

&lt;IfDefine !NOSSL&gt;<br />

Hata: Ya SSL ya da NOSSL tanımlı olmalı.<br />

&lt;/IfDefine&gt;<br />

&lt;/IfDefine&gt;<br />

</example>

</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> 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>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>

<example>

ErrorDocument 500 http://hata.example.com/cgi-bin/dnmci<br />

ErrorDocument 404 /cgi-bin/bad_urls.pl<br />

ErrorDocument 401 /subscription_info.html<br />

ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."

ErrorDocument 403 Yasak!

</example>

<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>

<example>

ErrorDocument 404 /cgi-bin/bad_urls.pl<br /><br />

&lt;Directory /web/docs&gt;<br />

<indent>

ErrorDocument 404 default<br />

</indent>

&lt;/Directory&gt;

</example>

<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>

<example><title>Örnek</title>

ErrorLog /var/log/httpd/error_log

</example>

<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>

<example><title>Örnek</title>

ErrorLog "|/usr/local/bin/httpd_errors"

</example>

<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>

<example><title>Örnek</title>

ErrorLog syslog:user

</example>

<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>

<compatibility>Apache httpd 2.3.9 ve sonrasında kullanılabilmektedir.

</compatibility>

<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>

<example><title>Basit örnek</title>

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client %a] %M"

</example>

<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 ilş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>

<example><title>Example (default format)</title>

ErrorLogFormat "[%{u}t] [%-m:%l] [pid %P:tid %T] %7F: %E: [client\ %a]

%M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"

</example>

<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>

<example><title>Örnek (2.2.x biçemine benzer)</title>

ErrorLogFormat "[%t] [%l] %7F: %E: [client\ %a]

%M%&nbsp;,\&nbsp;referer\&nbsp;%{Referer}i"

</example>

<example><title>İstek/bağlantı günlük kimlikli gelişkin bir örnek</title>

ErrorLogFormat "[%{uc}t] [%-m:%-l] [R:%L] [C:%{C}L] %7F: %E: %M"<br/>

ErrorLogFormat request "[%{uc}t] [R:%L] Request %k on C:%{c}L pid:%P tid:%T"<br/>

ErrorLogFormat request "[%{uc}t] [R:%L] UA:'%+{User-Agent}i'"<br/>

ErrorLogFormat request "[%{uc}t] [R:%L] Referer:'%+{Referer}i'"<br/>

ErrorLogFormat connection "[%{uc}t] [C:%{c}L] local\ %a remote\ %A"<br/>

</example>

</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:

<example>FileETag INode MTime Size</example></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. <code>~</code> imine ek olarak <glossary

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

<example>

&lt;Files ~ "\.(gif|jpe?g|png)$"&gt;

</example>

<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>

<example>

&lt;FilesMatch "\.(gif|jpe?g|png)$"&gt;

</example>

<p>satırı en bilinen resim dosyası biçimleriyle eşleşecektir.</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>

<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>

<example>

ForceType image/gif

</example>

<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>

<example>

# tüm dosyaların image/gif olarak sunulması için:<br />

&lt;Location /images&gt;<br />

<indent>

ForceType image/gif<br />

</indent>

&lt;/Location&gt;<br />

<br />

# normal MIME-türüne geri dönmek için:<br />

&lt;Location /images/mixed&gt;<br />

<indent>

ForceType None<br />

</indent>

&lt;/Location&gt;

</example>

<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>

</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>

<example>

&lt;If "-z req('Host')"&gt;

</example>

<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>

<example>

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

</example>

<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>

</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 ...<br />

<br />

# httpd.conf<br />

&lt;IfDefine ReverseProxy&gt;<br />

<indent>

LoadModule proxy_module modules/mod_proxy.so<br />

LoadModule proxy_http_module modules/mod_proxy_http.so<br />

&lt;IfDefine UseCache&gt;<br />

<indent>

LoadModule cache_module modules/mod_cache.so<br />

&lt;IfDefine MemCache&gt;<br />

<indent>

LoadModule mem_cache_module modules/mod_mem_cache.so<br />

</indent>

&lt;/IfDefine&gt;<br />

&lt;IfDefine !MemCache&gt;<br />

<indent>

LoadModule cache_disk_module modules/mod_cache_disk.so<br />

</indent>

&lt;/IfDefine&gt;

</indent>

&lt;/IfDefine&gt;

</indent>

&lt;/IfDefine&gt;

</example>

</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>Dosya kalıbıyla eşleşme 2.0.41 ve sonrasında, 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>

<example>

Include /usr/local/apache2/conf/ssl.conf<br />

Include /usr/local/apache2/conf/vhosts/*.conf

</example>

<p>Veya dizinler <directive module="core">ServerRoot</directive> dizinine

göre belirtilebilir:</p>

<example>

Include conf/ssl.conf<br />

Include conf/vhosts/*.conf

</example>

<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>

<example>

Include conf/vhosts/*/*.conf

</example>

<p>Bunun yerine, dizin ve dosyaların eksikliği durumunda aşağıdaki komut

sadece yoksayılır:</p>

<example>

IncludeOptional conf/vhosts/*/*.conf

</example>

</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>

<compatibility>Apache httpd 2.3.2'den itibaren milisaniyelik değerler belirtilebilmektedir.</compatibility>

<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 bağlamında, 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>

<example>

&lt;Limit POST PUT DELETE&gt;<br />

<indent>

Require valid-user<br />

</indent>

&lt;/Limit&gt;

</example>

<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>

<example>

&lt;LimitExcept GET&gt;

<indent>

Require valid-user

</indent>

&lt;/LimitExcept&gt;<br />

&lt;Limit POST&gt;

<indent>

Require group editors

</indent>

&lt;/Limit&gt;

</example>

</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>

<example>

&lt;LimitExcept POST GET&gt;<br />

<indent>

Require valid-user<br />

</indent>

&lt;/LimitExcept&gt;

</example>

</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>

<compatibility>Apache httpd 2.0.47 ve sonrasında mevcuttur.</compatibility>

<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>

<example><title>Örnek</title>

LimitInternalRecursion 5

</example>

</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>

<example>

LimitRequestBody 102400

</example>

<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>

<example>

LimitRequestFields 50

</example>

<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>

<example>

LimitRequestFieldSize 4094

</example>

<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>

<example>

LimitRequestLine 4094

</example>

<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>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>

<example>

LimitXMLRequestBody 0

</example>

</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>

<example>

&lt;Location /private1&gt;

...

</example>

<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>

<example>

&lt;Location /private2<em>/</em>&gt;

...

</example>

<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>

<example>

&lt;Location ~ "/(ek|hususi)/veri"&gt;

</example>

<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>

<example>

&lt;Location /status&gt;<br />

<indent>

SetHandler server-status<br />

Require host example.com<br />

</indent>

&lt;/Location&gt;

</example>

<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>

<example>

&lt;LocationMatch "/(ek|hususi)/veri"&gt;

</example>

<p>yönergesi <code>/ek/veri</code> ve <code>/hususi/veri</code> alt

dizgeleriyle eşleşecektir.</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>

<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>

<example>

LogLevel notice

</example>

<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>

<example>

LogLevel info ssl:warn<br />

LogLevel info mod_ssl.c:warn<br />

LogLevel info ssl_module:warn<br />

</example>

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

<example>

LogLevel info<br />

&lt;Directory /usr/local/apache/htdocs/app&gt;<br />

&nbsp; LogLevel debug<br />

&lt;/Files&gt;

</example>

<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şklendirilmemiş günlük

iletileri etkilenmez.</note>

</usage>

</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>

<example>

MaxKeepAliveRequests 500

</example>

</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>