Apache HTTP Sunucusu Sürüm 2.2

Apache > HTTP Sunucusu > Belgeleme > Sürüm 2.2 > Modüller

# Apache Temel Özellikleri

Mevcut Diller: de | en | fr | ja | tr

Açıklama: | Apache HTTP Sunucusunda daima mevcut olan çekirdek özellikler
Durum: | Çekirdek

### Yönergeler

## AcceptFilter Yönergesi

Açıklama: | Bir protokolün dinleyici soketleri için en iyilemeleri ayarlar
Sözdizimi: | `AcceptFilter protocol kabul_süzgeci`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.1.5 ve sonrasında mevcuttur.

Bu yönerge 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 FreeBSD’nin Kabul Süzgeçleri ve Linux’un soket seçeneklerinden `TCP_DEFER_ACCEPT` desteklenmektedir.

FreeBSD için öntanımlı değerler:

`AcceptFilter http httpready
AcceptFilter https dataready`

`httpready` 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 accf_http(9) kılavuz sayfasına bakınız. HTTPS istekleri şifrelenmiş olduğundan sadece accf_data(9) süzgeci kullanılır.

Linux’taki ön tanımlı değerler:

`AcceptFilter http data
AcceptFilter https data`

Linux’un `TCP_DEFER_ACCEPT` soket seçeneği HTTP isteklerinin tamponlanmasını desteklemez. `none` dahil her değer dinleyici üzerinde `TCP_DEFER_ACCEPT` seçeneğini etkin kılar. Daha ayrıntılı bilgi edinmek için Linux tcp(7) kılavuz sayfasına bakınız.

Argüman olarak `none` kullanımı o protokol için kabul süzgeçlerini iptal edecektir. Bu, `nntp` gibi, sunucunun baştan bir veri göndermesinin gerekli olduğu protokoller için kullanışlıdır:

`AcceptFilter nntp none`

### Ayrıca bakınız:

- `Protocol`

## AcceptPathInfo Yönergesi

Açıklama: | Dosya isminden sonra belirtilen yol verisini kabul veya reddeder.
Sözdizimi: | `AcceptPathInfo On|Off|Default`
Öntanımlı: | `AcceptPathInfo Default`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.0.30 ve sonrasında mevcuttur.

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 `PATH_INFO` ortam değişkeninde betiklerin kullanımına sunulabilir.

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

`AcceptPathInfo` yönergesine atanabilecek argüman sayısı üçtür:

`Off`
  Sadece dosya isminden sonra yol verisi bulunmayan istekler kabul edilir. Yukarıdaki örnekteki gibi `/test/here.html/more` şeklindeki istekler bir 404 (Nesne bulunamadı) hatasıyla sonuçlanır.
`On`
  Mevcut bir dosyaya ait bir dosya isminden sonra bir yol verisinin de belirtildiği istekler kabul edilir. Yukarıdaki örnekteki gibi `/test/here.html/more` şeklindeki istekler, `/test/here.html` geçerli bir dosya olduğu takdirde kabul edilir.
`Default`
  Dosya isminden sonra yol verisi belirtilen isteklerin nasıl ele alınacağı istekten sorumlu eylemci tarafından saptanır. Normal dosyalar için çekirdek eylemci öntanımlı olarak `PATH_INFO` isteklerini reddeder. `cgi-script` ve `isapi-handler` gibi betiklere hizmet eden eylemciler ise genellikle `PATH_INFO` isteklerini öntanımlı olarak kabul ederler.

`AcceptPathInfo` yönergesinin birincil amacı eylemcinin `PATH_INFO` istekleri hakkında verdiği kabul veya red kararını geçersiz kılabilmenizi sağlamaktır. Örneğin, `PATH_INFO`’ya dayalı olarak içerik üretmek için `INCLUDES` gibi bir süzgeç 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:

`<Files "mypaths.shtml">
Options +Includes
SetOutputFilter INCLUDES
AcceptPathInfo On
</Files>`

## AccessFileName Yönergesi

Açıklama: | Dağıtık yapılandırma dosyasının ismi belirtilir.
Sözdizimi: | `AccessFileName filename [filename] ...`
Öntanımlı: | `AccessFileName .htaccess`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

Belge yolu üzerindeki dizinlerde dağıtık yapılandırma dosyalarının bulunmasına izin verilmişse sunucu bir isteği işlerken önce bu dizinlerde bu yönergede belirtilmiş yapılandırma dosyasını arar. Örnek:

`AccessFileName .acl`

Sunucu, `/usr/local/web/index.html` belgesini döndürmeden önce,

`<Directory />
AllowOverride None
</Directory>`

şeklinde bir yapılandırma ile iptal edilmiş olmadıkça yönergeler için `/.acl`, `/usr/.acl`, `/usr/local/.acl` ve `/usr/local/web/.acl` dosyalarını okur.

### Ayrıca bakınız:

- `AllowOverride`
- Yapılandırma Dosyaları
- .htaccess Dosyaları

## AddDefaultCharset Yönergesi

Açıklama: | Bir yanıtın içerik türü `text/plain` veya `text/html` olduğunda eklenecek öntanımlı karakter kümesi parametresini belirler.
Sözdizimi: | `AddDefaultCharset On|Off|karküm`
Öntanımlı: | `AddDefaultCharset Off`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core

Bu yönerge, yanıtın içerik türü `text/plain` veya `text/html` 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 `META` elemanı vasıtasıyla belirtilmiş karakter kümesini geçersiz kılar. `AddDefaultCharset Off` şeklinde bir atama bu işlevselliği iptal eder. `AddDefaultCharset On` ile bu işlevsellik etkin kılınmaktan başka `iso-8859-1` karakter kümesini öntanımlı olarak yanıta eklenir. Yönergede karküm olarak belirtilecek değerler, MIME ortam türlerinde kullanmak üzere IANA’da kayıtlı karakter kümesi değerlerinden biri olmalıdır. Örnek:

`AddDefaultCharset utf-8`

`AddDefaultCharset` 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.

### Ayrıca bakınız:

- `AddCharset`

## AddOutputFilterByType Yönergesi

Açıklama: | Belli bir MIME türüne bir çıktı süzgeci atar.
Sözdizimi: | `AddOutputFilterByType süzgeç[;süzgeç...] MIME-türü [MIME-türü] ...`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | 2.0.33 ve sonrasında mevcuttur; Apache 2.1 ve sonrasında kullanımı önerilmemektedir.

Bu yönerge yanıtın MIME türüne bağlı olarak bir istek için belli bir çıktı süzgecini etkin kılar. Aşağıda açıklanan belli başlı sorunlardan dolayı bu yönergenin kullanımı önerilmemektedir. Aynı işlevsellik `mod_filter` kullanarak sağlanabilmektedir.

Aşağıdaki örnekte `mod_deflate` modülünce sağlanan `DEFLATE` süzgeci kullanılmıştır. Bu süzgeç, `text/html` veya `text/plain` olarak yaftalanmış tüm çıktıyı (ister durağan ister devingen olsun) istemciye göndermeden önce sıkıştırır.

`AddOutputFilterByType DEFLATE text/html text/plain`

İçeriğin birden fazla süzgeç tarafından işlenmesini isterseniz süzgeç isimlerini noktalı virgüllerle ayırarak belirtebilirsiniz. Ayrıca, bu süzgeçlerin her biri için ayrı bir `AddOutputFilterByType` yönergesi belirtmek de mümkündür.

Aşağıdaki yapılandırma `text/html` olarak yaftalanmış tüm betik çıktılarının önce `INCLUDES` sonra da `DEFLATE` süzgecinden geçirilmesine sebep olur.

`<Location /cgi-bin/>
Options Includes
AddOutputFilterByType INCLUDES;DEFLATE text/html
</Location>`

### Ek Bilgi

Süzgeçlerin `AddOutputFilterByType` ile etkin kılınması bazı durumlarda kısmen bazılarında da tamamen başarısızlığa uğrayabilir. Örneğin, MIME türü saptanamadığı takdirde hiçbir süzgeç uygulanmaz ve `DefaultType` aynı olsa bile son çare olarak `DefaultType` ayarlarına geri dönülür.

Bununla birlikte, süzgeçlerin uygulanacağına emin olmak isterseniz, bir kaynağa içerik türünü örneğin, `AddType` veya `ForceType` ile açıkça atayabilirsiniz. Ayrıca, içerik türünü (bir nph-olmayan) CGI betiği içinde ayarlamak da bu güvenceyi sağlar.

### Ayrıca bakınız:

- `AddOutputFilter`
- `SetOutputFilter`
- Süzgeçler

## AllowEncodedSlashes Yönergesi

Açıklama: | Kodlanmış dosya yolu ayracı içeren URL’lere izin verilip verilmeyeceğini belirler.
Sözdizimi: | `AllowEncodedSlashes On|Off|NoDecode`
Öntanımlı: | `AllowEncodedSlashes Off`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.0.46 ve sonrasında mevcuttur. NoDecode seçeneği 2.2.18 ve sonrasında kullanılabilir.

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

`Off` öntanımlı değeri ile böyle URL'ler bir 404 (bulunamadı) hatasıyla reddedilir.

`On` değeri ile böyle URL'ler kabul edilir ve kodlanmış bölü çizgileri diğer kodlanmış karakterler gibi çözümlenir.

`NoDecode` değeri ile böyle URL'ler kabul edilir fakat kodlanmış bölü çizgileri çözümlenmeden bırakılır.

`AllowEncodedSlashes` `On`, çoğunlukla `PATH_INFO` ile bir arada kullanıldığı zaman kullanışlıdır.

### Ek Bilgi

`PATH_INFO` içinde kodlanmış bölü çizgilerini kullanmaktan başka çare yoksa bir güvenlik ölçütü olarak `NoDecode` kullanmanız şiddetle tavsiye edilir. Bölü çizgilerinin çözümlenmeye çalışılması yanlış yol çözümlemesi gibi güvenilmez bir olasılığa yol açabilir.

### Ayrıca bakınız:

- `AcceptPathInfo`

## AllowOverride Yönergesi

Açıklama: | `.htaccess` dosyalarında bulunmasına izin verilen yönerge türleri belirtilir.
Sözdizimi: | `AllowOverride All|None|yönerge-türü [yönerge-türü] ...`
Öntanımlı: | `AllowOverride All`
Bağlam: | dizin
Durum: | Çekirdek
Modül: | core

Sunucu `AccessFileName` yönergesi ile belirtildiği şekilde bir `.htaccess` dosyasına rastlarsa önceki yapılandırma yönergelerinin hangilerinin geçersiz kılınmak üzere bildirildiğini bilmek ister.

### Sadece <Directory> bölümlerinde geçerli

`AllowOverride` yönergesi, `<Location>`, `<DirectoryMatch>` veya `<Files>` bölümlerinde değil, sadece düzenli ifade içermeyen `<Directory>` bölümlerinde geçerlidir.

Yönergeye değer olarak `None` belirtilirse .htaccess dosyaları tamamen yok sayılır. Bu durumda, sunucu dosya sisteminde rastladığı `.htaccess` dosyalarını okumaya dahi çalışmayacaktır.

Bu yönergeye `All` değeri atanırsa, .htaccess bağlamında kullanılabilecek her yönergeye `.htaccess` dosyalarında izin verilir.

`yönerge-türü` olarak aşağıdaki yönerge grup isimlerinden biri belirtilebilir:

AuthConfig
  `AuthDBMGroupFile`, `AuthDBMUserFile`, `AuthGroupFile`, `AuthName`, `AuthType`, `AuthUserFile`, `Require` ve benzeri yetkilendirme yönergelerinin kullanımını izin verilir.
FileInfo
  Belge türünü denetleyen `mod_mime` `Add*` ve `Remove*` yönergeleri, `DefaultType`, `ErrorDocument`, `ForceType`, `LanguagePriority`, `SetHandler`, `SetInputFilter`, `SetOutputFilter` yönergeleri ve benzerleri ile `Header`, `RequestHeader`, `SetEnvIf`, `SetEnvIfNoCase`, `BrowserMatch`, `CookieExpires`, `CookieDomain`, `CookieStyle`, `CookieTracking`, `CookieName` belge meta veri yönergelerinin, `mod_rewrite` modülündeki `RewriteEngine`, `RewriteOptions`, `RewriteBase`, `RewriteCond`, `RewriteRule` yönergelerinin ve `mod_actions` modülündeki `Action` yönergesinin kullanımına izin verilir.
Indexes
  Dizin içeriğinin listelenmesini denetleyen `AddDescription`, `AddIcon`, `AddIconByEncoding`, `AddIconByType`, `DefaultIcon`, `DirectoryIndex`, `FancyIndexing`, `HeaderName`, `IndexIgnore`, `IndexOptions`, `ReadmeName` yönergelerinin ve benzerlerinin kullanımına izin verilir.
Limit
  Konak erişimini denetleyen `Allow`, `Deny` ve `Order` yönergelerinin kullanımına izin verilir.
Options[=seçenek,...]
  Dizinlere özgü özellikleri denetleyen `Options` ve `XBitHack` yönergelerinin kullanımına izin verilir. `Options` komutunda belirtilecek seçenekler bir eşit işaretinden sonra aralarına sadece virgül konarak (boşluksuz) belirtilebilir.

  ### Seçeneklerin örtük iptali

  .htaccess dosyalarında kullanılabilecek seçenekler bu yönergeyle sınırlanabileceği gibi miras alınmış bir seçenek olarak, bağıntısız sözdizimi kullanılarak iptal edilebilen herhangi bir seçenek de `Options` yönergesi ile dolaylı olarak iptal edilmiş olacaktır. Başka bir deyişle, bu mekanizma evvelce etkisiz kılınmış bir seçeneğin etkin kılınmasını sağlamayacaktır.

Örnek:

`AllowOverride AuthConfig Indexes`

Bu örnekte `AuthConfig` ve `Indexes` grubundaki yönergeler bir dahili sunucu hatasına yol açmayacaktır.

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

### Ayrıca bakınız:

- `AccessFileName`
- Yapılandırma Dosyaları
- .htaccess Dosyaları

## AuthName Yönergesi

Açıklama: | HTTP kimlik doğrulamasında kullanmak için yetki alanı ismi
Sözdizimi: | `AuthName yetki-alanı`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | AuthConfig
Durum: | Çekirdek
Modül: | core

Bu yönerge bir dizin için yetki alanı ismi belirler. Bu alan istemciye bildirilerek kullanıcının hangi kullanıcı ismini ve parolasını kullanacağını bilmesi sağlanır. `AuthName` tek bir argüman alır. Bu bakımdan eğer alan ismi boşluk karakterleri içeriyorsa ismin tırnak içine alınması gerekir. Çalışması için `AuthUserFile` ve `AuthGroupFile` gibi yönergelerden başka `AuthType` ve `Require` yönergelerinin kendine eşlik etmesini gerektirir.

Örnek:

`AuthName "Top Secret"`

`AuthName` için belirtilen dizge çoğu tarayıcı tarafından parola diyaloğunda gösterilir.

### Ayrıca bakınız:

- Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi

## AuthType Yönergesi

Açıklama: | Kullanıcı kimlik doğrulaması türü
Sözdizimi: | `AuthType Basic|Digest`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | AuthConfig
Durum: | Çekirdek
Modül: | core

Bu yönerge bir dizin için kullanıcı kimlik doğrulaması türünü belirler. Olası kimlik doğrulama türleri `Basic` (`mod_auth_basic` modülüyle sağlanır) ve `Digest`’tir (`mod_auth_digest` modülüyle sağlanır).

Kimlik doğrulamasının gerçekleşmesi için `AuthName` ve `Require` yönergelerini de kullanmalısınız. Bunlara ek olarak sunucunun `mod_authn_file` gibi bir kimlik doğrulayıcı modülüne ve `mod_authz_user` gibi bir yetkilendirme modülüne ihtiyacı vardır.

### Ayrıca bakınız:

- Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi

## CGIMapExtension Yönergesi

Açıklama: | CGI betik yorumlayıcısını saptama tekniğini belirler.
Sözdizimi: | `CGIMapExtension cgi-yolu .uzantı`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Sadece NetWare’de geçerlidir.

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

## ContentDigest Yönergesi

Açıklama: | `Content-MD5` HTTP yanıt başlıklarının üretimini etkin kılar.
Sözdizimi: | `ContentDigest On|Off`
Öntanımlı: | `ContentDigest Off`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | Options
Durum: | Çekirdek
Modül: | core

Bu yönerge RFC2616 ve RFC1864’te tanımlandığı gibi `Content-MD5` üretimini etkin kılar.

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.

`Content-MD5` 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:

`Content-MD5: AuLb7Dp1rqtRtxz2m9kRpA==`

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

`Content-MD5`, herhangi bir modül değil, sadece `core` 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.

## DefaultType Yönergesi

Açıklama: | Sunucunun MIME türünü saptayamadığı durumda göndereceği MIME içerik türünü belirler.
Sözdizimi: | `DefaultType MIME-türü|none`
Öntanımlı: | `DefaultType text/plain`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | `none` değeri Apache 2.2.7 ve sonrasında mevcuttur.

Sunucudan zaman zaman kendi MIME türü ile uyuşmayan bir belge sunması istenir.

Sunucu, belgenin içerik türünü istemciye bildirmek zorundadır. Eğer sunucu bunu normal yollardan saptayamazsa içerik türü olarak `DefaultType` ile belirtilen değeri gönderir. Örneğin, GIF dosyaları bulunan bir dizinde `.gif` uzantısına sahip olmayan dosyaların da bulunması durumunda, bu dizin için,

`DefaultType image/gif`

belirtilmesi uygun olurdu.

İçerik türünün ne sunucu ne de yönetici (örneğin, vekil) tarafından saptanabildiği durumlarda MIME türünün yanlış belirtilmesindense tür belirtmemek tercih edilebilir. Bu, şöyle yapılabilir:

`DefaultType None`

`DefaultType None` sadece httpd-2.2.7 ve sonrasında mevcuttur.

Bu yönergenin sadece öntanımlı MIME-türünü sağlaması nedeniyle `ForceType` yönergesinden farklı olduğuna dikkat ediniz. Dosya ismi uzantıları dahil, tüm diğer MIME-türü tanımları ortam türünü tanımladığı noktada bu öntanımlı türü sunulan veri için geçersiz kılacaktır.

## <Directory> Yönergesi

Açıklama: | Sadece ismi belirtilen dosya sistemi dizinine ve bunun altdizinleri ile içeriklerine uygulanacak bir yönerge grubunu sarmalar.
Sözdizimi: | `<Directory dizin-yolu> ... </Directory>`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

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

`<Directory /usr/local/httpd/htdocs>
Options Indexes FollowSymLinks
</Directory>`

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

`~` karakterine ek olarak düzenli ifadeler de kullanılabilir. Örnek:

`<Directory ~ "^/www/.*/[0-9]{3}">`

yönergesi `/www/` içindeki üç rakamdan oluşan dizinlerle eşleşecektir.

Eğer çok sayıda (düzenli ifade olmayan) `<Directory>` 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 .htaccess dosyalarındaki yönergelere kadar genişletilir. Örneğin,

`<Directory />
AllowOverride None
</Directory>
<Directory /home>
AllowOverride FileInfo
</Directory>`

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

- `AllowOverride None` yönergesi uygulanır (`.htaccess` dosyaları iptal edilir).
- `AllowOverride FileInfo` yönergesi uygulanır (`/home` dizini için).
- Sırayla `/home/.htaccess`, `/home/web/.htaccess` ve `/home/web/dir/.htaccess` dosyaları içindeki `FileInfo` yönergeleri uygulanır.

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,

`<Directory ~ abc$>
# ... yönergeler burada ...
</Directory>`

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

`<Directory />` için öntanımlı Apache erişiminin `Allow from All` oluşuna dikkat ediniz. Bunu şöyle bir blokla değiştirmeniz,

`<Directory />
Order Deny,Allow
Deny from All
</Directory>`

ve erişilebilir olmasını istediğiniz dizinleri ayrıca belirtmeniz önerilir. Daha ayrıntılı bilgi edinmek için Güvenlik İpuçları belgesine bakınız.

Dizin bölümleri `httpd.conf` dosyasında yer alır. `<Directory>` yönergeleri iç içe olamazlar ve bir `<Limit>` veya `<LimitExcept>` bölümü içinde bulunamazlar.

### Ayrıca bakınız:

- Bir istek alındığında farklı yapılandırma bölümlerinin nasıl bir arada ele alındığının anlatıldığı <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine de bakınız.

## <DirectoryMatch> Yönergesi

Açıklama: | Bir düzenli ifade ile eşleşen dosya sistemi dizininde ve bunun altdizinlerinde uygulanacak bir yönerge grubunu sarmalar.
Sözdizimi: | `<DirectoryMatch düzifd> ... </DirectoryMatch>`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`<DirectoryMatch>` and `</DirectoryMatch>` yönergeleri `<Directory>` gibi sadece ismi belirtilen dosya sistemi dizinine ve bunun altdizinleri ile bunların içerdiği dosyalara uygulanacak bir yönerge grubunu sarmalamakta kullanılır. Tek farkla argüman olarak bir düzenli ifade alır. Örnek:

`<DirectoryMatch "^/www/(.+/)?[0-9]{3}">`

yönergesi `/www/` içindeki üç rakamdan oluşan dizinlerle eşleşecektir.

### Satırsonu karakteri

Satırsonu karakteri ($) bu yönerge ile eşleşemez.

### Ayrıca bakınız:

- Normal `<Directory>` bölümlerindeki yönergelerle düzenli ifadelerin nasıl karıştırıldığının bir açıklaması için `<Directory>` yönergesine bakınız.
- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

## DocumentRoot Yönergesi

Açıklama: | İstemciye görünür olan ana belge ağacının kök dizinini belirler.
Sözdizimi: | `DocumentRoot dizin-yolu`
Öntanımlı: | `DocumentRoot /usr/local/apache/htdocs`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

Bu yönerge `httpd` tarafından dosyalarının sunulacağı dizini belirler. `Alias` 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:

`DocumentRoot /usr/web`

yapılandırması ile `http://www.my.host.com/index.html` isteği `/usr/web/index.html` ile eşleştirilir. dizin-yolu ile göreli dosya yolu belirtildiği takdirde belge kök dizininin `ServerRoot` ile belirtilen sunucu kök dizinine göre belirtildiği varsayılır.

`DocumentRoot` ile belirtilen dizin bir bölü çizgisi ile bitirilmemelidir.

### Ayrıca bakınız:

- URL’lerin Dosya Sistemi ile Eşlenmesi

## EnableMMAP Yönergesi

Açıklama: | Teslimat sırasında okunacak dosyalar için bellek eşlemeyi etkin kılar.
Sözdizimi: | `EnableMMAP On|Off`
Öntanımlı: | `EnableMMAP On`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core

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, `mod_include` 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, işletim sistemi tarafından desteklendiği takdirde dosyayı belleğe eşler.

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:

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

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:

`EnableMMAP Off`

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

`<Directory "/nfs-dosya-yolu"> EnableMMAP Off </Directory>`

## EnableSendfile Yönergesi

Açıklama: | Dosyaların istemciye tesliminde çekirdeğin dosya gönderme desteğinin kullanımını etkin kılar.
Sözdizimi: | `EnableSendfile On|Off`
Öntanımlı: | `EnableSendfile On`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | 2.0.44 ve sonrasında mevcuttur.

Bu yönerge, dosya içeriğinin istemciye teslimi için `httpd`’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, işletim sistemi tarafından destekleniyorsa dosyayı istemciye teslim etmek için çekirdeğin dosya gönderme özelliğini kullanır.

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

- 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.
- Linux’ta IPv6 kullanırken dosya gönderme desteği bazı ağ kartlarındaki TCP toplama sağlaması aktarım hatasını tetikler.
- Itanium üzerinde çalışan Linux’ta dosya gönderme desteği 2GB’tan büyük dosyalarla çalışamamaktadır.
- `DocumentRoot` ağ dosya sistemi (NFS veya SMB gibi) üzerinde olduğu durumda çekirdek ağ dosyalarını kendi arabelleği üzerinden sunamayabilir.

Bu sorunlardan muzdarip sunucu yapılandırmaları için bu özelliği şöyle iptal edebilirsiniz:

`EnableSendfile Off`

Bu özellik, sadece bir NFS veya SMB dosya sistemi üzerinde sunulan dosyaları kapsamak üzere şu şekilde kolayca kapatılabilir:

`<Directory "/path-to-nfs-files"> EnableSendfile Off </Directory>`

`EnableSendfile` yönergesinin .htaccess ve diziniçi yapılandırmalarının `mod_disk_cache` tarafından desteklenmediğini lütfen aklınızdan çıkarmayın. `EnableSendfile` yönergesinin sadece küresel tanımları hesaba katılır.

## ErrorDocument Yönergesi

Açıklama: | Bir hata durumunda sunucunun istemciye ne döndüreceğini belirler.
Sözdizimi: | `ErrorDocument hata-kodu belge`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Metin iletilerini tırnak içine alma sözdizimi Apache 2.0’da farklıdır.

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

1. Yerleşik bir hata iletisi çıktılanır.
2. Özel bir ileti çıktılanır.
3. Sorunu/hatayı işleyecek yerel bir URL-yoluna yönlendirme yapılır.
4. Sorunu/hatayı işleyecek harici bir URL-yoluna yönlendirme yapılır.

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

URL’ler yerel yollarda (`DocumentRoot`’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:

`ErrorDocument 500 http://hata.meselae.dom/cgi-bin/dnmci
ErrorDocument 404 /cgi-bin/bad_urls.pl
ErrorDocument 401 /subscription_info.html
ErrorDocument 403 "Kusura bakmayın, bugün hizmet veremiyoruz."`

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

`ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>`

`ErrorDocument` yönergesinde bir uzak URL (önünde `http` bulunan bir yol) belirtildiğinde, belge aynı sunucuda olsa bile, Apache’nin 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, `ErrorDocument 401` 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, ihtiyaç duyduğunuz takdirde, `ErrorDocument 401` yönergesine yerel bir belge belirtmelisiniz.

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 Q294807 kodlu Microsoft Knowledge Base makalesinde bulabilirsiniz.

Çoğu yerleşik hata iletisi özel iletilerle değiştirilebilse de bazı durumlarda `ErrorDocument` 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.

`mod_proxy` kullanıyorsanız, gerekirse vekili olunan sunucu yararına özel hata iletileri üretmenizi sağlayabilen `ProxyErrorOverride` yönergesini etkin kılabilirsiniz. Bu yönergeyi etkinleştirmezseniz Apache vekaleten sunulan içerik için özel hata sayfaları üretmeyecektir.

2.0 öncesi sürümlerde iletiler bir çift çift-tırnak içine alınmayıp, tek bir çift-tırnak ile başlatılması yeterli olurdu.

### Ayrıca bakınız:

- Özel Hata Yanıtları

## ErrorLog Yönergesi

Açıklama: | Sunucunun hata günlüğünü tutacağı yeri belirler.
Sözdizimi: | `ErrorLog dosya-yolu|syslog[:oluşum]`
Öntanımlı: | `ErrorLog logs/error_log (Unix) ErrorLog logs/error.log (Windows ve OS/2)`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`ErrorLog` yönergesi sunucunun saptadığı hataları kaydedeceği dosyanın ismini belirtmek için kullanılır. dosya-yolu ile göreli dosya yolu belirtildiği takdirde dizininin `ServerRoot` ile belirtilen sunucu kök dizinine göre belirtildiği varsayılır.

### Örnek

`ErrorLog /var/log/httpd/error_log`

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

### Örnek

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

Daha fazla bilgi edinmek için borulu günlükler ile ilgili ek bilgilere bakınız.

Dosya adı yerine `syslog` kullanılırsa, sistem desteklediği takdirde günlük kaydı syslogd(8) üzerinden yürütülür. Öntanımlı olarak `local7` syslog oluşumu kullanılır. Bunu `syslog:oluşum` sözdizimini kullanarak değiştirebilirsiniz. Buradaki `oluşum` syslog.conf(5) kılavuz sayfasında belirtilen oluşum isimlerinden biri olabilir.

### Örnek

`ErrorLog syslog:user`

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 güvenlik ipuçları belgesinde ayrıntılı olarak açıklanmıştır.

### Ek Bilgi

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.

### Ayrıca bakınız:

- `LogLevel`
- Apache Günlük Dosyaları

## FileETag Yönergesi

Açıklama: | `ETag`Duruk dosyalar için HTTP yanıt başlığını oluşturmakta kullanılacak dosya özniteliklerini belirler.
Sözdizimi: | `FileETag bileşen ...`
Öntanımlı: | `FileETag INode MTime Size`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core

`FileETag` yönergesi, belge bir duruk dosyaya dayandığı takdirde `ETag` (Entity Tag - öğe etiketi kısaltması) yanıt başlığı alanını oluşturmakta kullanılacak dosya özniteliklerini yapılandırır. (`ETag` değeri, ağ band genişliğinden kazanmak için arabellek yönetiminde kullanılır.) Apache 1.3.22 ve öncesinde `ETag` değeri daima dosyanın düğümü, boyutu ve son değişiklik zamanından (mtime) oluşurdu. `FileETag` yönergesi ne kullanılması gerektiğini belirleyebilmenizi sağlar. Değer olarak belirtilebilecek anahtar sözcükler şunlardır:

INode
  Dosyanın düğüm numarası hesaba katılır.
MTime
  Dosyanın son değişiklik tarih ve saati dahil edilir.
Size
  Dosyanın bayt cinsinden uzunluğu dahil edilir.
All
  Olası tüm alanlar kullanılır. Bu şuna eşdeğerdir:

  `FileETag INode MTime Size`

None
  Bir belge dosyasıyla sunulsa bile yanıta hiçbir `ETag` alanı dahil edilmez.

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

Eğer bir dizinin yapılandırması `FileETag INode MTime Size` ve alt dizini `FileETag -INode` içeriyorsa bu alt dizinin (ve bir geçersizleştirme olmadığı takdirde onun alt dizinlerinin) ayarları `FileETag MTime Size` yapılandırmasına eşdeğer olacaktır.

### Uyarı

WebDAV’ın etkin olduğu yerlerde veya dizinlerde saklama alanı sağlayıcı olarak `mod_dav_fs` kullanılıyorsa öntanımlı ayarları değiştirmeyiniz. `mod_dav_fs`, koşullu isteklerde `ETag` karşılaştırmaları yapabilmek için `INode MTime Size` yapılandırmasını kullanır. Eğer `ETag` ayarı `FileETag` yönergesi kullanılarak değiştirilirse koşullu istekler gerektiği gibi yerine getirilemez.

### Sunucu Taraflı İçerik (SSI)

`mod_include` tarafından çözümlenen yanıtlar için bie ETag üretilmez. Bunun sebebi, gömülü SSI yönergeleri ile duruk dosyanın boyutunda, değişiklik zamanında ve dosya düğümünde bir değişiklik olmaksızın yanıt öğesinin değişebilmesidir.

## <Files> Yönergesi

Açıklama: | Dosya isimleriyle eşleşme halinde uygulanacak yönergeleri içerir.
Sözdizimi: | `<Files dosya-adı> ... </Files>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

dosya-adı argümanının bir dosya ismi veya bir dosya ismi kalıbı içermesi gerekir. Bir dosya ismi kalıbındaki her `?` imi bir karakterle eşleştirilirken `*` imi karakter dizileri ile eşleştirilir. `~` imine ek olarak düzenli ifadeler de kullanılabilir. Örneğin

`<Files ~ "\.(gif|jpe?g|png)$">`

satırı en bilinen resim dosyası biçimleriyle eşleşecektir. Bunun yerine `<FilesMatch>` yönergesi de tercih edilebilirdi.

`<Directory>` ve `<Location>` bölümlerinin aksine, `<Files>` bölümleri `.htaccess` dosyaları içinde kullanılabilir. Bu sayede kullanıcıların kendi dosyalarına erişimi dosya seviyesinde denetlemelerine imkan sağlanmış olur.

### Ayrıca bakınız:

- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

## <FilesMatch> Yönergesi

Açıklama: | Düzenli ifadelerin dosya isimleriyle eşleşmesi halinde uygulanacak yönergeleri içerir.
Sözdizimi: | `<FilesMatch düzifd> ... </FilesMatch>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

`<FilesMatch>` yönergesi, içerdiği yönergelerin etki alanını `<Files>` yönergesinin yaptığı gibi dosya isimlerine göre sınırlandırır. Ancak, argüman olarak bir düzenli ifade kabul eder. Örneğin

`<FilesMatch "\.(gif|jpe?g|png)$">`

satırı en bilinen resim dosyası biçimleriyle eşleşecektir.

### Ayrıca bakınız:

- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

## ForceType Yönergesi

Açıklama: | Bütün dosyaların belirtilen MIME içerik türüyle sunulmasına sebep olur.
Sözdizimi: | `ForceType MIME-türü|None`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.0’da core modülüne taşındı.

Bu yönerge, bir `.htaccess` dosyası veya bir `<Directory>`, `<Location>` veya `<Files>` bölümüne yerleştirildiği zaman, eşleşen tüm dosyaların MIME-türü 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 `.gif` uzantısı belirtmek istemiyorsanız şu yapılandırmayı kullanabilirsiniz:

`ForceType image/gif`

`DefaultType` yönergesinin tersine bu yönerge ortam türünü betimleyen tüm MIME-türü tanımlarını geçersiz kılar.

Mevcut `ForceType` ayarlarını `None` değeriyle geçersiz kılabilirsiniz:

`# tüm dosyaların image/gif olarak sunulması için:
<Location /images>
ForceType image/gif
</Location>
# normal MIME-türüne geri dönmek için:
<Location /images/mixed>
ForceType None
</Location>`

## GprofDir Yönergesi

Açıklama: | gmon.out profilleme verisinin yazılacağı dizin.
Sözdizimi: | `GprofDir /tmp/gprof/|/tmp/gprof/%`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

Sunucu gprof profilleme desteği ile derlendiği takdirde `GprofDir` yönergesi, süreç çıkarken `gmon.out` dosyalarının belirtilen dizine yazılmasını sağlar. Eğer değistirge yüzde simgesi (%) ile bitirilirse her süreç kimliği (PID) için ayrı bir aldizin oluşturulur.

Bu yönerge sadece `prefork` MPM ile çalışır.

## HostnameLookups Yönergesi

Açıklama: | İstemci IP adresleri üzerinde DNS sorgularını etkin kılar.
Sözdizimi: | `HostnameLookups On|Off|Double`
Öntanımlı: | `HostnameLookups Off`
Bağlam: | sunucu geneli, sanal konak, dizin
Durum: | Çekirdek
Modül: | core

Bu yönerge oturum açabilecek konak isimlerini tespit edebilmek için DNS sorgularını etkin kılar (ve sonuç `REMOTE_HOST`’ta belirtilerek CGI/SSI’lere aktarılır). `Double` 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 `PARANOID` adı verilir.)

Konak ismine göre erişimi denetlemek için `mod_authz_host` 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 `HostnameLookups Double` belirtilmedikçe genellikle çift yönlü sorgulama yapılmaz. Örneğin, sadece `HostnameLookups On` 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 `REMOTE_HOST` olarak tek yönlü sorgu sonucu aktarılır.

Gerçekte ters yönlü sorguya gerek duyulmayan sitelerde ağ trafiğini yormamak için `Off`, ö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 `Off` olarak bırakılmalıdır. Öntanımlı olarak kurulum dizininizin `bin` alt dizinine kurulan `logresolve` uygulaması kullanılarak oturum açan IP adresleri için isim sorguları çevrim dışıyken yapılabilir.

## <IfDefine> Yönergesi

Açıklama: | Başlatma sırasında bir doğruluk sınamasından sonra işleme sokulacak yönergeleri sarmalar.
Sözdizimi: | `<IfDefine [!]parametre-adı> ... </IfDefine>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

`<IfDefine sınama>...</IfDefine>` bölümü koşullu olarak işleme sokulacak yönergeleri içerir. Bir `<IfDefine>` bölümü içindeki yönergeler sadece sınama doğru sonuç verirse işleme sokulur. Aksi takdirde, bölüm içinde kalan her şey yok sayılır.

`<IfDefine>` bölüm yönergesinde sınama için belirtilebilecek iki biçim vardır:

- parametre-adı
- `!`parametre-adı

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

parametre-adı argümanı sunucu başlatılırken `httpd` komut satırında `-Dparametre` ile belirtilerek tanımlı hale getirilebilir.

`<IfDefine>` bölümleri iç içe olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir. Örnek:

`httpd -DReverseProxy -DUseCache -DMemCache ...
# httpd.conf
<IfDefine ReverseProxy>
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<IfDefine UseCache>
LoadModule cache_module modules/mod_cache.so
<IfDefine MemCache>
LoadModule mem_cache_module modules/mod_mem_cache.so
</IfDefine>
<IfDefine !MemCache>
LoadModule disk_cache_module modules/mod_disk_cache.so
</IfDefine> </IfDefine> </IfDefine>`

## <IfModule> Yönergesi

Açıklama: | Belli bir modülün varlığına veya yokluğuna göre işleme sokulacak yönergeleri sarmalar.
Sözdizimi: | `<IfModule [!]modül-dosyası|modül-betimleyici> ... </IfModule>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Modül betimleyiciler 2.1 sürümünde ve sonrası için geçerlidir.

`<IfModule sınama>...</IfModule>` bölümü belli bir modülün varlığına veya yokluğuna göre işleme sokulacak yönergeleri içerir. Bir `<IfModule>` bölümü içindeki yönergeler sadece sınama doğru sonuç verirse işleme sokulur. Aksi takdirde, bölüm içinde kalan her şey yok sayılır.

`<IfModule>` bölüm yönergesinde sınama için belirtilebilecek iki biçim vardır:

- modül
- !modül

Birinci durumda bölüm içinde kalan yönergeler sadece modül ile belirtilen modül Apache içine dahil edilmişse veya `LoadModule` yönergesi ile devingen olarak yüklenmişse işleme sokulur. İkinci durumda ise tersi yapılır, yani sadece modül içerilmiş değil ise yönergeler işleme sokulur.

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

`<IfModule>` bölümleri iç içe olabilir, dolayısıyla çok parametreli basit sınamalar gerçeklenebilir.

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 `<IfModule>` bölümlerine yerleştirilmeleri gerekmez.

## Include Yönergesi

Açıklama: | Sunucu yapılandırma dosyalarının başka dosyaları içermesini sağlar.
Sözdizimi: | `Include dosya-yolu|dizin-yolu`
Bağlam: | sunucu geneli, sanal konak, dizin
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Dosya kalıbıyla eşleşme 2.0.41 ve sonrasında mevcuttur.

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

Çok sayıda dosyayı bir kerede alfabetik sırada içermek için kabuk tarzı (`fnmatch()`) dosya ismi kalıp karakterleri kullanılabilir. Ayrıca, eğer `Include` yönergesi bir dosya değil de bir dizin gösteriyorsa Apache bu dizindeki ve alt dizinlerindeki bütün dosyaları okuyacaktır. Fakat dizinin bir bütün olarak okutulması önerilmez, çünkü dizinde `httpd` programının çökmesine sebep olabilecek geçici dosyalar unutulabilir.

Dosya yolu mutlak bir dosya yolu olarak belirtilebileceği gibi `ServerRoot` dizinine göreli olarak da belirtilebilir.

Örnekler:

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

Veya dizinler `ServerRoot` dizinine göre belirtilebilir:

`Include conf/ssl.conf
Include conf/vhosts/*.conf`

### Ayrıca bakınız:

- `apachectl`

## KeepAlive Yönergesi

Açıklama: | HTTP kalıcı bağlantılarını etkin kılar
Sözdizimi: | `KeepAlive On|Off`
Öntanımlı: | `KeepAlive On`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`Keep-Alive` 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 `KeepAlive On` şeklinde kullanılır.

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.

Bir istemci kalıcı bağlantı kullandığı takdirde, bağlantı üzerinden kaç istek gönderilirse gönderilsin, `MaxRequestsPerChild` yönergesi bakımından tek bir istek olarak değerlendirilir.

### Ayrıca bakınız:

- `MaxKeepAliveRequests`

## KeepAliveTimeout Yönergesi

Açıklama: | Bir kalıcı bağlantıda sunucunun bir sonraki isteği bekleme süresi
Sözdizimi: | `KeepAliveTimeout saniye`
Öntanımlı: | `KeepAliveTimeout 5`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

Sunucunun kalıcı bir bağlantıyı kapatmadan önce bir sonraki isteği kaç saniye bekleyeceğini belirler. İstek alındıktan sonra `Timeout` yönergesiyle belirtilen zaman aşımı değeri uygulanır.

`KeepAliveTimeout` 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.

İsme dayalı sanal konak bağlamında, `NameVirtualHost` bölümleri içinde tanımlanmış ilk sanal konağın (öntanımlı konak) değeri kullanılır. Diğer değerler görmezden gelinir.

## <Limit> Yönergesi

Açıklama: | Erişimi sınırlanacak HTTP yöntemleri için erişim sınırlayıcıları sarmalar.
Sözdizimi: | `<Limit yöntem [yöntem] ... > ... </Limit>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

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

`<Limit POST PUT DELETE>
Require valid-user
</Limit>`

Birden fazla bölümde kullanılabilecek yöntem isimleri: `GET`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `PATCH`, `PROPFIND`, `PROPPATCH`, `MKCOL`, `COPY`, `MOVE`, `LOCK` ve `UNLOCK`. Yöntem isimleri harf büyüklüğüne duyarlıdır. `GET` yöntemi sınırlanırsa `HEAD` istekleri de sınırlanmış olur. `TRACE` yöntemi sınırlanamaz.

Erişimi sınarlarken bir `<Limit>` bölümü yerine daima bir `<LimitExcept>` bölümünü tercih etmelisiniz, çünkü `<LimitExcept>` bölümü belirtilen yöntemler dışında kalanlara erişim koruması sağlar.

## <LimitExcept> Yönergesi

Açıklama: | İsimleri belirtilenler dışında kalan HTTP yöntemleri için kullanılacak erişim sınırlayıcıları sarmalar.
Sözdizimi: | `<LimitExcept yöntem [yöntem] ... > ... </LimitExcept>`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

`<LimitExcept>` ve `</LimitExcept>` argüman olarak belirtilenler dışında kalan HTTP yöntemleri için kullanılacak erişim sınırlayıcıları gruplamakta kullanılır. Yani, `<Limit>` 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 `<Limit>` yönergesinin açıklamasına bakınız.

Örnek:

`<LimitExcept POST GET>
Require valid-user
</LimitExcept>`

## LimitInternalRecursion Yönergesi

Açıklama: | Dahili yönlendirmelerin ve istek içi isteklerin azami sayısını belirler.
Sözdizimi: | `LimitInternalRecursion sayı [sayı]`
Öntanımlı: | `LimitInternalRecursion 10`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.0.47 ve sonrasında mevcuttur.

Örneğin, özgün istekleri dahili olarak bir CGI betiğine yönlendiren `Action` 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’nin kullandığı bir mekanizmadır. Örneğin, `mod_dir`, `DirectoryIndex` yönergesinde listelenen dosyalara bakmak için istek içi istekler kullanır.

`LimitInternalRecursion` 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.

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

### Örnek

`LimitInternalRecursion 5`

## LimitRequestBody Yönergesi

Açıklama: | İstemci tarafından gönderilen HTTP istek gövdesinin toplam uzunluğunu sınırlar.
Sözdizimi: | `LimitRequestBody bayt-sayısı`
Öntanımlı: | `LimitRequestBody 0`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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.

`LimitRequestBody` 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. `PUT` 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.

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, ö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:

`LimitRequestBody 102400`

Dikkat: Vekil isteklerine uygulanamaz.

## LimitRequestFields Yönergesi

Açıklama: | İstemciden kabul edilecek HTTP isteği başlık alanlarının sayısını sınırlar.
Sözdizimi: | `LimitRequestFields sayı`
Öntanımlı: | `LimitRequestFields 100`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

sayı, 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 `DEFAULT_LIMIT_REQUEST_FIELDS` ile belirlenir (dağıtımla gelen değeri 100’dür).

`LimitRequestFields` 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.

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.

Örnek:

`LimitRequestFields 50`

### Uyarı

İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri, bağlantının eşleştirildiği ilk `NameVirtualHost` yönergesinden (listedeki ilk - öntanımlı - konak) alınır.

## LimitRequestFieldSize Yönergesi

Açıklama: | İstemciden kabul edilecek HTTP isteği başlık uzunluğunu sınırlar.
Sözdizimi: | `LimitRequestFieldSize bayt-sayısı`
Öntanımlı: | `LimitRequestFieldSize 8190`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

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

`LimitRequestFieldSize` yönergesi, sunucu yöneticilerine HTTP istek başlık alanının azami uzunluğunu arttırıp azaltma 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.

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.

Örnek:

`LimitRequestFieldSize 4094`

Normal şartlar altında öntanımlı değer değiştirilmemelidir.

### Uyarı

İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri, bağlantının eşleştirildiği ilk `NameVirtualHost` yönergesinden (listedeki ilk - öntanımlı - konak) alınır.

## LimitRequestLine Yönergesi

Açıklama: | İstemciden kabul edilecek HTTP istek satırının uzunluğunu sınırlar.
Sözdizimi: | `LimitRequestLine bayt-sayısı`
Öntanımlı: | `LimitRequestLine 8190`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

Bu yönerge, HTTP istek satırında izin verilecek bayt sayısını belirler.

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

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.

Örnek:

`LimitRequestLine 4094`

Normal şartlar altında öntanımlı değer değiştirilmemelidir.

### Uyarı

İsme dayalı sanal konaklar kullanılıyorsa bu yönergenin değeri, bağlantının eşleştirildiği ilk `NameVirtualHost` yönergesinden (listedeki ilk - öntanımlı - konak) alınır.

## LimitXMLRequestBody Yönergesi

Açıklama: | Bir XML temelli istek gövdesinin uzunluğunu sınırlar.
Sözdizimi: | `LimitXMLRequestBody bayt-sayısı`
Öntanımlı: | `LimitXMLRequestBody 1000000`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

Örnek:

`LimitXMLRequestBody 0`

## <Location> Yönergesi

Açıklama: | İçerdiği yönergeler sadece eşleşen URL’lere uygulanır.
Sözdizimi: | `<Location URL-yolu|URL> ... </Location>`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

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

`<Location>` bölümleri dosya sisteminin tamamen dışında işlem görürler. Bunun çeşitli sonuçları olur. En önemlisi, `<Location>` 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.

URL-yolu bileşeni aşağıdaki koşullardan herhangi birine uyduğu takdirde kapsanan yönergeler isteğe uygulanacaktır:

- URL'nin yol bileşeni belirtilen konum ile eşleşir.
- URL'nin yol bileşeninin başındaki bölü çizgisi, belirtilen konumun sonundaki bölü çizgisi ile eşleşir (içeriğin kök dizini olarak ele alınır).
- URL'nin yol bileşeninin başındaki bölü çizgisi, belirtilen konumun sonuna bir bölü çizgisi eklenerek bununla eşleşir (içeriğin kök dizini olarak ele alınır)

Aşağıdaki örnekte, sonda bir bölü çizgisi kullanılmamış olmasına rağmen /herhangi1, /herhangi1/ ve /herhangi1/dosya.txt dizgilerini içeren isteklere kapsanan yönergeler uygulanacak, ancak /herhangi1baskasi dizgisini içeren bir isteğe uygulanmayacaktır.

`<Location /herhangi1> ...`

Aşağıdaki örnekte, sonda bir bölü çizgisi kullanılmış olup, /herhangi2, /herhangi2/ ve /herhangi2/dosya.txt dizgilerini içeren isteklere kapsanan yönergeler uygulanacak, ancak /herhangi2baskasi dizgisini içeren bir isteğe uygulanmayacaktır.

`<Location /private2/> ...`

### `<Location>` ne zaman kullanılmalı

`<Location>` 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 `<Directory>` ve `<Files>` bölümlerini kullanın. Bunun istisnası, sunucunun tamamına bir yapılandırma uygulamak için kolay bir yol olan `<Location />` kullanımıdır.

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

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

Ayrıca, `~` karakteri eşliğinde düzenli ifadeler de kullanılabilir. Örneğin,

`<Location ~ "/(ek|hususi)/veri">`

yönergesi `/ek/veri` ve `/hususi/veri` alt dizgeleriyle eşleşecektir. `<LocationMatch>` yönergesi `<Location>` yönergesinin düzenli ifade sürümüne eşdeğer davranır.

`<Location>` işlevselliği özellikle `SetHandler` yönergesi ile birlikte kullanışlı olur. Örneğin, durum isteklerini etkin kılmak ama sadece `mesela.dom`’dan gelen isteklere izin vermek için şöyle bir uygulama yapabilirsiniz:

`<Location /status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .mesela.dom
</Location>`

### / (bölü çizgisi) hakkında

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, `/home///foo` ile `/home/foo` aynıdır). URL uzayında bunun böyle olması gerekli değildir. Eğer çok sayıda bölü çizgisini yanyana belirtmeniz gerekiyorsa `<LocationMatch>` yönergesinde ve `<Location>` yönergesinin düzenli ifadeli kullanımında bunu açıkça belirtmeniz gerekir.

Örneğin, `<LocationMatch ^/abc>` yönergesi `/abc` ile eşleşecek ama `//abc` ile eşleşmeyecektir. `<Location>` 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, `<Location /abc/def>` belirtirseniz ve istek `/abc//def` şeklinde olursa bu ikisi eşleşir.

### Ayrıca bakınız:

- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

## <LocationMatch> Yönergesi

Açıklama: | İçerdiği yönergeler sadece düzenli ifadelerle eşleşen URL’lere uygulanır.
Sözdizimi: | `<LocationMatch düzifade> ... </LocationMatch>`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`<LocationMatch>` yönergesi içerdiği yönergelerin etki alanını `<Location>` yönergesinin yaptığı gibi belirtilen URL’lerle sınırlar. Ancak argüman olarak basit bir dizge değil bir düzenli ifade alır. Örneğin,

`<LocationMatch "/(ek|hususi)/veri">`

yönergesi `/ek/veri` ve `/hususi/veri` alt dizgeleriyle eşleşecektir.

### Ayrıca bakınız:

- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

## LogLevel Yönergesi

Açıklama: | Hata günlüklerinin ayrıntı seviyesini belirler.
Sözdizimi: | `LogLevel seviye`
Öntanımlı: | `LogLevel warn`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`LogLevel` yönergesi hata günlüklerine kaydedilen hata iletilerinde hangi ayrıntılara yer verileceğini belirler (`ErrorLog` yönergesine bakınız). En yüksek önem derecesinden başlayarak olası seviye değerleri aşağıda sıralanmıştır:

Seviye | Açıklama | Örnek
--- | --- | ---
`emerg` | Acil durumlar - sistem kullanışsız. | "Child cannot open lock file. Exiting" (Alt süreç kilit dosyasını açamıyor. Çıkılıyor)
`alert` | Ne yapılacaksa beklemeden yapılmalı. | "getpwuid: couldn't determine user name from uid" (getpwuid: Kullanıcı ismi numarasından saptanamadı)
`crit` | Kriz durumları. | "socket: Failed to get a socket, exiting child" (socket: bir soket alınamadı, alt süreç çıkıyor)
`error` | Hata durumları. | "Premature end of script headers" (Betik başlıkları beklenmedik şekilde bitti)
`warn` | Uyarı durumları. | "child process 1234 did not exit, sending another SIGHUP" (1234 alt süreci çıkmadı, başka bir SIGHUP gönderiliyor)
`notice` | Normal fakat önemli durum. | "httpd: caught SIGBUS, attempting to dump core in ..." (httpd: SIGBUS alındı, core dökümlenmeye çalışılıyor: ...)
`info` | Bilgilendirme. | "Server seems busy, (you may need to increase StartServers, or Min/MaxSpareServers)..." (Sunucu meşgul görünüyor, (StartServers veya Min/MaxSpareServers değerlerini arttırmanız gerekebilir)...)
`debug` | Hata ayıklama seviyesi iletileri | "Opening config file ..." (... yapılandırma dosyası açılıyor)

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

En az `crit` seviyesinin kullanılması önerilir.

Örnek:

`LogLevel notice`

### Ek Bilgi

Günlük iletileri normal bir dosyaya yazılırken `notice` seviyesinden iletiler engellenemez ve dolayısıyla daima raporlanırlar. Ancak, günlük kaydı `syslog` kullanılarak yapılıyorsa bu uygulanmaz.

## MaxKeepAliveRequests Yönergesi

Açıklama: | Bir kalıcı bağlantıda izin verilen istek sayısı
Sözdizimi: | `MaxKeepAliveRequests sayı`
Öntanımlı: | `MaxKeepAliveRequests 100`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`MaxKeepAliveRequests` yönergesi `KeepAlive` etkinken bağlantı başına izin verilecek istek sayısını sınırlar. Değer olarak `0` 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.

Örnek:

`MaxKeepAliveRequests 500`

## NameVirtualHost Yönergesi

Açıklama: | İsme dayalı sanal konaklar için IP adresi belirtir
Sözdizimi: | `NameVirtualHost adres[:port]`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core

`NameVirtualHost` yönergesi isme dayalı sanal konakları yapılandırmak isterseniz gerekli olur.

adres olarak bir konak ismi de belirtebilirsiniz ama daima bir IP adresi ve bir port kullanmanızı öneririz. Örnek:

`NameVirtualHost 111.22.33.44:80`

`NameVirtualHost` yönergesi ile sunucunun isme dayalı sanal konaklar için istekleri hangi IP adresinden alacağı belirtilir. Bu adres genellikle isme dayalı sanal konak isimleri çözümlendiğinde elde edilen IP adresidir. İstekleri bir güvenlik duvarının veya bir vekilin alıp sunucuya yönlendirdiği durumlarda ise bu adres sunucunun istekleri aldığı fiziksel arabirimin IP adresi olmalıdır. Çok sayıda adres üzerinde çok sayıda isme dayalı sanal konak varsa her adresin kendi yönergeleri olmalıdır.

### Ek Bilgi

“Ana sunucu” ve `_default_` sunucuların bir `NameVirtualHost` IP adresine yapılan bir isteği asla sunmayacağına dikkat ediniz (bir sebeple `NameVirtualHost` belirtip bu adres için herhangi bir `VirtualHost` tanımlamadığınız durumlar hariç).

Seçimlik olarak, isme dayalı sanal konakların kullanması gereken port numarasını örnekteki gibi belirtebilirsiniz:

`NameVirtualHost 111.22.33.44:8080`

IPv6 adresleri belirtilirken örnekteki gibi köşeli ayraçlar arasına alınmalıdır:

`NameVirtualHost [2001:db8::a00:20ff:fea7:ccea]:8080`

İsteklerin bütün arabirimlerden alınacağını belirtmek için değer olarak `*:80` veya eğer çok sayıda portu dinliyorsanız ve belli bir sanal konak kümesi üzerinden sunucunun hepsine yanıt vermesini istiyorsanız `*` belirtebilirsiniz:

`NameVirtualHost *:80`

### `<VirtualHost>` yönergesinin argümanı

`<VirtualHost>` yönergesinin argümanının `NameVirtualHost` yönergesininkiyle tam olarak eşleşmesi gerektiğine dikkat ediniz.

`NameVirtualHost 1.2.3.4:80
<VirtualHost 1.2.3.4:80>
# ...
</VirtualHost>
`

### Ayrıca bakınız:

- Apache Sanal Konak Belgeleri

## Options Yönergesi

Açıklama: | Belli bir dizinde geçerli olacak özellikleri yapılandırır.
Sözdizimi: | `Options [+|-]seçenek [[+|-]seçenek] ...`
Öntanımlı: | `Options All`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | Options
Durum: | Çekirdek
Modül: | core

`Options` yönergesi belli bir dizinde hangi sunucu özelliklerinin etkin olacağını (veya olmayacağını) belirler.

seçenek olarak hiçbir ek özellik etkin olmayacaksa `None`, aksi takdirde aşağıdakilerden biri veya bir kaçı belirtilir:

`All`
  `MultiViews` hariç tüm seçenekler. Bu öntanımlıdır.
`ExecCGI`
  `mod_cgi` kullanan CGI betiklerinin çalışmasına izin verilir.
`FollowSymLinks`
  Sunucu bu dizindeki sembolik bağları izler.

  Sembolik bağlar izlense bile `<Directory>` bölümleriyle eşleşen dosya yolları değiştirilmez.

  Ayrıca, bu seçenek bir `<Location>` bölümü içinde belirtildiği takdirde yok sayılır.

  Sembolik bağ sınamaları, atlatılabilir yarış koşullarına konu olduğundan bu seçeneğin yokluğu bir güvenlik sınırlaması olarak değerlendirilmemelidir.

`Includes`
  `mod_include` tarafından sağlanan sunucu taraflı içeriklere izin verilir.
`IncludesNOEXEC`
  Sunucu taraflı içeriklere izin verilir fakat `#exec cmd` ve `#exec cgi` iptal edilir. Ancak, `ScriptAlias`’lı dizinlerdeki CGI betikleri için `#include virtual` hala mümkün olacaktır.
`Indexes`
  İstenen URL bir dizin ile eşleşiyorsa ve bu dizin için bir `DirectoryIndex` (`index.html` gibi) belirtilmemişse `mod_autoindex` bu dizinin biçimlenmiş bir listesini döndürecektir.
`MultiViews`
  `mod_negotiation` kullanılarak içerik uzlaştırmalı çok görünümlü içeriğe izin verilir.
`SymLinksIfOwnerMatch`
  Sunucu sembolik bağları sadece sembolik bağın hedefi ile bulunduğu dizinin sahibinin aynı kullanıcı olması halinde izleyecektir.

  ### Ek Bilgi

  Bu seçenek bir `<Location>` bölümü içinde belirtildiğinde yok sayılır.

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

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

### Uyarı

`+` veya `-` imli seçenekler içeren `Options` ile imsiz seçenekler içerenlerin karışık olarak kullanılması beklenmedik sonuçlara yol açması sebebiyle aslında geçersiz bir sözdizimidir.

Örneğin, `+` ve `-` imleri olmaksızın,

`<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options Includes
</Directory>`

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

`<Directory /web/docs>
Options Indexes FollowSymLinks
</Directory>
<Directory /web/docs/spec>
Options +Includes -Indexes
</Directory>`

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

### Ek Bilgi

`-IncludesNOEXEC` veya `-Includes` kullanımı, önceki ayarların ne olduğuna bakılmaksızın sunucu taraflı içeriğin tamamen iptaline sebep olur.

Herhangi bir başka değer belirtilmedikçe `All` öntanımlıdır.

## Protocol Yönergesi

Açıklama: | Dinlenen bir soket için protokol
Sözdizimi: | `Protocol protokol`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Windows üzerinde Apache 2.3.3 ve sonrasında diğerlerinde ise Apache 2.1.5 ve sonrasında kullanılabilmektedir.

Bu yönerge dinlenen belli bir soket için protokol belirtmek amacıyla kullanılır. Protokol, bir isteği hangi modülün işleyeceğini belirlemekte ve `AcceptFilter` yönergesi ile ilgili protokole özgü iyileştirmeleri uygulamakta kullanılır.

Bu yönergeyi sadece standartdışı portlar belirtecekseniz kullanın. Normalde `http` için 80, `https` için 443 portu kullanılır.

Örneğin, `https`'i standartdışı bir port üzerinde çalıştırıyorsanız bunu şöyle belirtebilirsiniz:

`Protocol https`

Kullandığınız protoklü ayrıca `Listen` yönergesini kullanarak da belirtebilirsiniz.

### Ayrıca bakınız:

- `AcceptFilter`
- `Listen`

## Require Yönergesi

Açıklama: | Bir özkaynağa erişebilecek kimliği doğrulanmış kullanıcıları belirler
Sözdizimi: | `Require öğe-adı [öğe-adı] ...`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | AuthConfig
Durum: | Çekirdek
Modül: | core

Bu yönerge br özkaynağa erişebilecek kimliği doğrulanmış kullanıcıları belirlemek için kullanılır. Belli bir kullanıcı veya kullanıcı grubuna erişim vermek için bu yönergeden çok sayıda yazmak yerine bunlar mantıksal VEYAlarla birleştirilebilir. Kısıtlamalar yetkilendirme modülleri tarafından işleme sokulur. `mod_authz_user` ve `mod_authz_groupfile` tarafından izin verilen bazı sözdizimleri:

`Require user kull-kiml [kull-kiml] ...`
  Sadece belirtilen kullanıcılar özkaynağa erişebilir.
`Require group grup-adı [grup-adı] ...`
  Sadece belirtilen gruplara üye kullanıcılar özkaynağa erişebilir.
`Require valid-user`
  Geçerli kullanıcıların hepsi özkaynağa erişebilir.

Gerekli diğer seçenekleri sağlayan yetkilendirme modülleri olarak `mod_authnz_ldap`, `mod_authz_dbm` ve `mod_authz_owner` sayılabilir.

`Require` yönergesinin düzgün çalışması için kendisine `AuthName` ve `AuthType` yönergelerinin yanı sıra kullanıcıları ve grupları tanımlamak için `AuthUserFile` ve `AuthGroupFile` gibi yönergelerinin de eşlik etmesi gerekir. Örnek:

`AuthType Basic
AuthName "Restricted Resource"
AuthUserFile /web/users
AuthGroupFile /web/groups
Require group admin`

Bu yolla uygulanan erişim denetimleri tüm yöntemler için etkilidir. Normalde istenen zaten budur. Erişim denetimlerini diğerlerini korumasız bırakmak pahasına sadece belli yöntemlerle sınırlamak isterseniz `Require` yönergesini bir `<Limit>` bölümüne yerleştirin.

Eğer `Require` yönergesini `Allow` veya `Deny` yönergeleri ile birlikte kullanırsanız bu sınırlamalarla olan etkileşim `Satisfy` yönergesi tarafından denetlenir.

### Denetimlerin alt dizinlerden kaldırılması

Aşağıdaki örnekte korunmuş bir dizinin bir alt dizinindeki erişim denetimlerinin kaldırılması için `Satisfy` yönergesinin nasıl kullanılacağı gösterilmiştir. Bu teknik, `mod_authz_host` tarafından dayatılan erişim denetimlerini de ortadan kaldırdığından dikkatli kullanılmalıdır.

`<Directory /korunmuş/dizine/giden/yol/>
Require user david
</Directory>
<Directory /korunmuş/dizine/giden/yol/korunmamış-dizin/>
# Bu dizinde tüm erişim denetimleri ve kimlik doğrulaması
# iptal ediliyor
Satisfy Any
Allow from all
</Directory>
`

### Ayrıca bakınız:

- Kimlik Doğrulama, Yetkilendirme ve Erişim Denetimi
- `Satisfy`
- `mod_authz_host`

## RLimitCPU Yönergesi

Açıklama: | Apache alt süreçleri tarafından çalıştırılan süreçlerin işlemci tüketimine sınırlama getirir.
Sözdizimi: | `RLimitCPU saniye|max [saniye|max]`
Öntanımlı: | `Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

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

İşlemci özkaynak sınırları saniye cinsinden ifade edilir.

### Ayrıca bakınız:

- `RLimitMEM`
- `RLimitNPROC`

## RLimitMEM Yönergesi

Açıklama: | Apache alt süreçleri tarafından çalıştırılan süreçlerin bellek tüketimine sınırlama getirir.
Sözdizimi: | `RLimitMEM bayt-sayısı|max [bayt-sayısı|max]`
Öntanımlı: | `Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

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

Bellek özkaynak sınırları süreç başına bayt sayısı olarak ifade edilir.

### Ayrıca bakınız:

- `RLimitCPU`
- `RLimitNPROC`

## RLimitNPROC Yönergesi

Açıklama: | Apache alt süreçleri tarafından çalıştırılabilecek süreç sayısına sınırlama getirir.
Sözdizimi: | `RLimitNPROC sayı|max [sayı|max]`
Öntanımlı: | `Bir değer belirtilmemiştir; işletim sistemi öntanımlıları kullanılır`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

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

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

### Ek Bilgi

CGI süreçleri sunucu kullanıcı kimliğinden farklı bir kullanıcı kimliği altında çalışmıyorsa bu yönerge sunucunun kendi oluşturduğu süreç sayısını sınırlayacaktır. Bunun kanıtı `error_log`’da iletilerin çatallanamamasıdır.

### Ayrıca bakınız:

- `RLimitMEM`
- `RLimitCPU`

## Satisfy Yönergesi

Açıklama: | Konak seviyesinde erişim denetimi ile kullanıcı kimlik doğrulaması arasındaki etkileşim
Sözdizimi: | `Satisfy Any|All`
Öntanımlı: | `Satisfy All`
Bağlam: | dizin, .htaccess
Geçersizleştirme: | AuthConfig
Durum: | Çekirdek
Modül: | core
Uyumluluk: | 2.0.51 sürümü ve sonrasında `<Limit>` ve `<LimitExcept>` tarafından etkin kılınır.

`Allow` ve `Require` yönergelerinin ikisi birden kullanıldığında uygulanacak erişim kuralını belirler. Değer olarak sadece `All` veya `Any` belirtilebilir. Bu yönergenin yararlı olabilmesi için belli bir alana hem istemci konak adresi hem de kullanıcı ismi ve parolası belirtmek suretiyle erişilebiliyor olunması gerekir. Bu durumda öntanımlı davranış (`All`), istemcinin belli bir adrese erişebilmek için belli kısıtlamaları aşması ve geçerli bir kullanıcı adı ve parola girmesi gerekir. `Any` seçeneğinin belirtildiği durumda ise istemcinin ya konak kısıtlamalarıdan geçmesi ya da geçerli bir kullanıcı adı ve parolası girmesi gerekir. Bu seçenek, belli bir alana erişimi parolayla kısıtlayıp, belli adreslerden gelen kullanıcılara parolasız erişim vermek için kullanılabilir.

Örneğin, sitenizin belli bir bölümü için iç ağınızdan gelen isteklere sınırsız erişim vermek ama dışardan gelen istekleri parolayla kısıtlamak isterseniz şöyle bir yapılandırma kullanabilirsiniz:

`Require valid-user
Order allow,deny
Allow from 192.168.1
Satisfy Any`

2.0.51 sürümünden itibaren `Satisfy` yönergeleri `<Limit>` ve `<LimitExcept>` bölümleri tarafından belli yöntemlerle kısıtlanmış olabilir.

### Ayrıca bakınız:

- `Allow`
- `Require`

## ScriptInterpreterSource Yönergesi

Açıklama: | CGI betikleri için yorumlayıcı belirleme tekniği
Sözdizimi: | `ScriptInterpreterSource Registry|Registry-Strict|Script`
Öntanımlı: | `ScriptInterpreterSource Script`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Sadece Win32 için; `Registry-Strict` seçeneği Apache 2.0 ve sonrası için geçerlidir.

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

`#!C:/Perl/bin/perl.exe`

`perl` yorumlayıcının yeri `PATH` değişkeninde kayıtlı ise şöyle de olabilir:

`#!perl`

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

Örneğin, .pl uzantılı bir betiğin perl ile işlenmesi için sicil ayarı şöyle olabilir:

``HKEY_CLASSES_ROOT\.pl\Shell\ExecCGI\Command\(Default) => C:\Perl\bin\perl.exe -wT``

### Güvenlik

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

`Registry-Strict` seçeneği Apache 2.0’da yeni olup `Registry` seçeneğinin yaptığını `Shell\ExecCGI\Command` yolu için yapar. `ExecCGI` sistem tarafından bilinen bir anahtar olmadığından Windows Siciline elle kaydedilmesi gerekir ve dolayısıyla sisteminiz üzerinde istenmeyen program çağrılarına sebep olmaz.

## ServerAdmin Yönergesi

Açıklama: | Sunucunun hata iletilerinde istemciye göstereceği eposta adresi
Sözdizimi: | `ServerAdmin eposta-adresi|URL`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

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

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

`ServerAdmin www-admin@falan.filan.dom`

## ServerAlias Yönergesi

Açıklama: | İstekleri isme dayalı sanal konaklarla eşleştirilirken kullanılacak konak adları için başka isimler belirtebilmeyi sağlar.
Sözdizimi: | `ServerAlias konakadı [konakadı] ...`
Bağlam: | sanal konak
Durum: | Çekirdek
Modül: | core

`ServerAlias` yönergesi, istekleri isme dayalı sanal konaklarla eşleştirilirken kullanılacak konak adları için başka isimler belirtebilmeyi sağlar. `ServerAlias` dosya adı kalıp karakterleri içerebilir.

`<VirtualHost *:80>
ServerName sunucu.mesela.dom
ServerAlias sunucu sunucu2.mesela.dom sunucu2
ServerAlias *.mesela.dom
UseCanonicalName Off
# ...
</VirtualHost>`

### Ayrıca bakınız:

- `UseCanonicalName`
- Apache Sanal Konak Belgeleri

## ServerName Yönergesi

Açıklama: | Sunucunun özdeşleşeceği konak ismi ve port.
Sözdizimi: | `ServerName [şema://]tam-nitelenmiş-alan-adı[:port]`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Bu yönerge 2.0 sürümünden itibaren 1.3 sürümündeki `Port` yönergesinin işlevselliğini de üstlenmiştir.

`ServerName` yönergesi, sunucunun kendini betimlemekte kullanacağı şema, konak adı ve port değerlerini belirler. Bu, yönlendirme URL’leri oluşturulurken kullanılır.

Buna ek olarak, `ServerName` yönergesi isme dayali sanal konaklar kullanılması durumunda, bir sanal konağı tam olarak belirlemek için de kullanlır (muhtemelen `ServerAlias` ile birlikte).

Örneğin, HTTP sunucusunun barındırıldığı makinenin ismi `falan.filan.dom` olduğu halde makinenin bir de `www.filan.dom` diye bir de DNS rumuzu varsa ve HTTP sunucunuzun bu rumuzla kendini özdeşleştirmesini isterseniz bunu şöyle belirtebilirsiniz:

`ServerName www.filan.dom`

Bir `ServerName` ataması yapılmamışsa sunucu IP adresine atanmış sunucu ismi için bir ters DNS sorgusu yapacaktır. `ServerName` yönergesinde bir port belirtilmediği takdirde sunucu, isteğin geldiği portu kullanacaktır. Öngörülebilirlik ve güvenilirlik açısından en iyisi `ServerName` yönergesini kullanarak açıkça bir konak ismi ve port belirtmektir.

İsme dayalı sanal konaklar kullanıyorsanız, `<VirtualHost>` bölümü içindeki `ServerName` yönergesi, isteğin `Host:` başlığında bu sanal konakla eşleşecek konak ismini belirler.

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

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

### Ayrıca bakınız:

- DNS ile ilgili konular ve Apache
- Apache Sanal Konak Belgeleri
- `UseCanonicalName`
- `UseCanonicalPhysicalPort`
- `NameVirtualHost`
- `ServerAlias`

## ServerPath Yönergesi

Açıklama: | Uyumsuz bir tarayıcı tarafından erişilmesi için bir isme dayalı sanal konak için meşru URL yolu
Sözdizimi: | `ServerPath URL-yolu`
Bağlam: | sanal konak
Durum: | Çekirdek
Modül: | core

`ServerPath` yönergesi isme dayalı sanal konaklarda kullanmak için konağa meşru bir URL yolu belirler.

### Ayrıca bakınız:

- Apache Sanal Konak Belgeleri

## ServerRoot Yönergesi

Açıklama: | Sunucu yapılandırması için kök dizin
Sözdizimi: | `ServerRoot dizin-yolu`
Öntanımlı: | `ServerRoot /usr/local/apache`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core

`ServerRoot` yönergesi sunucu yapılandırmasını içeren dizinin yerini belirtir. Genellikle `conf/` ve `logs/` gibi alt dizinler içerir. `Include`, `LoadModule` gibi diğer yapılandırma yönergelerindeki göreli yollar bu dizine göre ele alınır.

### Örnek

`ServerRoot /home/httpd`

### Ayrıca bakınız:

- `httpd` için `-d` seçeneği
- `ServerRoot` dizininin erişim izinlerinin nasıl ayarlanması gerektiğini öğrenmek için güvenlik ipuçları

## ServerSignature Yönergesi

Açıklama: | Sunucu tarafından üretilen belgelerin dipnotunu ayarlar.
Sözdizimi: | `ServerSignature On|Off|EMail`
Öntanımlı: | `ServerSignature Off`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | All
Durum: | Çekirdek
Modül: | core

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

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

2.0.44 sürümünden beri sunucu sürüm numarasının ayrıntıları `ServerTokens` yönergesi ile belirlenmektedir.

### Ayrıca bakınız:

- `ServerTokens`

## ServerTokens Yönergesi

Açıklama: | `Server` HTTP yanıt başlığını yapılandırır.
Sözdizimi: | `ServerTokens Major|Minor|Min[imal]|Prod[uctOnly]|OS|Full`
Öntanımlı: | `ServerTokens Full`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core

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

`ServerTokens Prod[uctOnly]`
  Sunucu şunu gönderir (örnek): `Server: Apache`
`ServerTokens Major`
  Sunucu şunu gönderir (örnek): `Server: Apache/2`
`ServerTokens Minor`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.0`
`ServerTokens Min[imal]`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.0.41`
`ServerTokens OS`
  Sunucu şunu gönderir (örnek): `Server: Apache/2.0.41 (Unix)`
`ServerTokens Full` (ya da belirtilmezse)
  Sunucu şunu gönderir (örnek): `Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2`

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

2.0.44 sürümünden itibaren bu yönerge `ServerSignature` yönergesi tarafından sunulan bilgiyi de etkilemektedir.

### Ayrıca bakınız:

- `ServerSignature`

## SetHandler Yönergesi

Açıklama: | Eşleşen tüm dosyaların belli bir eylemci tarafından işlenmesine sebep olur.
Sözdizimi: | `SetHandler eylemci-ismi|None`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 2.0’da core modülüne taşındı.

Bir `.htaccess` dosyasına veya bir `<Directory>` ya da `<Location>` bölümüne yerleştirildiğinde, eşleşen tüm dosyaların, ismi eylemci-ismi ile belirtilen eylemci tarafından çözümlenmesine sebep olur. Örneğin, bir dizin içindeki bütün dosyaların, uzantılarına bakılmaksızın birer imagemap kural dosyası olarak çözümlenmesini istersiniz, bu dizin içindeki bir `.htaccess` dosyasına şöyle bir satır koyabilirsiniz:

`SetHandler imap-file`

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

`<Location /status>
SetHandler server-status
</Location>`

Evvelce tanımlanmış bir `SetHandler` yönergesini `None` değeriyle geçersiz hale getirebilirsiniz.

### Ayrıca bakınız:

- `AddHandler`

## SetInputFilter Yönergesi

Açıklama: | POST girdilerini ve istemci isteklerini işleyecek süzgeçleri belirler.
Sözdizimi: | `SetInputFilter süzgeç[;süzgeç...]`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core

`SetInputFilter` yönergesi, istemci isteklerini ve sunucu tarafından alındığı takdirde POST girdisini işleyecek süzgeç veya süzgeçleri belirler. Bu, diğer `AddInputFilter` yönergeleri dahil evvelce tanımlanmış süzgeçlere eklenir.

Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak sıralanmalıdırlar.

### Ayrıca bakınız:

- Süzgeçler belgesi

## SetOutputFilter Yönergesi

Açıklama: | Sunucunun yanıtlarını işleyecek süzgeçleri belirler.
Sözdizimi: | `SetOutputFilter süzgeç[;süzgeç...]`
Bağlam: | sunucu geneli, sanal konak, dizin, .htaccess
Geçersizleştirme: | FileInfo
Durum: | Çekirdek
Modül: | core

`SetOutputFilter` yönergesi, istemciye gönderilmeden önce sunucunun yanıtlarını işleyecek süzgeçleri belirler. Bu, diğer `AddOutputFilter` yönergeleri dahil evvelce tanımlanmış süzgeçlere eklenir.

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

`<Directory /www/data/>
SetOutputFilter INCLUDES
</Directory>`

Birden fazla süzgeç belirtilmek istenirse birbirlerinden noktalı virgüllerle ayrılmalı ve çıktıyı işleyecekleri sıraya uygun olarak sıralanmalıdırlar.

### Ayrıca bakınız:

- Süzgeçler belgesi

## Suexec Yönergesi

Açıklama: | suEXEC özelliğini açar veya kapar
Sözdizimi: | `Suexec On|Off`
Öntanımlı: | `suexec çalıştırılabiliri doğru sahip ve kip ile mevcutsa etkin kılınır, yoksa etkin kılınmaz.`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache httpd 2.2.18 ve sonrasında kullanılabilir.

Yönergeye On değeri verildiğinde, suexec çalıştırılabiliri mevcut değilse veya çalıştırılabilir dosyanın sahibi veya kip geçersizse sunucu başlatılamaz.

Off değeri verildiğinde ise, suexec çalıştırılabiliri doğru sahip ve kip ile mevcutsa bile suEXEC iptal edilir.

## TimeOut Yönergesi

Açıklama: | Bir istek için başarısız olmadan önce belirli olayların gerçekleşmesi için sunucunun geçmesini bekleyeceği süre.
Sözdizimi: | `TimeOut saniye`
Öntanımlı: | `TimeOut 300`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core

`TimeOut` yönergesi çeşitli durumlarda Apache’nin bekleyeceği süreyi belirler:

1. Veri istemciden okunurken, okuma tamponu boş olduğunda bir TCP paketinin gelmesi için beklenecek süre.
2. Veri istemciye yazılırken, gönderim tamponu dolu olduğunda bir paket alındı bilgisi için beklenecek süre.
3. `mod_cgi` modülünde bir CGI betiğinin çıktısı için beklenecek süre.
4. `mod_ext_filter` modülünde bir süzme işleminin çıktısı için beklenecek süre.
5. `mod_proxy` modülünde `ProxyTimeout` yapılandırılmamışsa öntanımlı zaman aşımı değeri.

## TraceEnable Yönergesi

Açıklama: | `TRACE` isteklerinde davranış şeklini belirler
Sözdizimi: | `TraceEnable [on|off|extended]`
Öntanımlı: | `TraceEnable on`
Bağlam: | sunucu geneli, sanal konak
Durum: | Çekirdek
Modül: | core
Uyumluluk: | Apache 1.3.34, 2.0.55 ve sonrasında mevcuttur.

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

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

## UseCanonicalName Yönergesi

Açıklama: | Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
Sözdizimi: | `UseCanonicalName On|Off|DNS`
Öntanımlı: | `UseCanonicalName Off`
Bağlam: | sunucu geneli, sanal konak, dizin
Durum: | Çekirdek
Modül: | core

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

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

Bir örnek olarak, iç ağdaki istemcilerin sunucuya `www` gibi bir kısa isim kullanarak bağlandığı durumu ele alırsak daha yararlı olur. Kullanıcılar bir kısa isim ve bir dizin isminden oluşan ve bir / ile sonlandırılmamış `http://www/splat` şeklinde bir istek yaparlarsa, Apache onları `http://www.mesela.dom/splat/` adresine yönlendirecektir. Eğer kimlik doğrulama da etkinse bu kullanıcının iki defa kimlik doğrulamasına sokulmasına sebep olacaktır (bir kere `www` için bir kere de `www.mesela.dom` için; daha ayrıntılı bilgi için SSS’y e bakınız). Fakat `UseCanonicalName Off` olsaydı Apache isteği `http://www/splat/` adresine yönlendirecekti.

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

### Uyarı

Eğer CGI’ler `SERVER_NAME` değerleri için önkabuller yapıyorlarsa bu seçenek işlerinin bozulmasına yol açabilir. Aslında istemciler konak ismi olarak istedikleri değeri vermekte özgürdürler. Fakat eğer CGI, özüne yönelik URL’leri oluştururken sadece `SERVER_NAME` değerini kullanıyorsa bu istendiği gibi çalışacaktır.

### Ayrıca bakınız:

- `UseCanonicalPhysicalPort`
- `ServerName`
- `Listen`

## UseCanonicalPhysicalPort Yönergesi

Açıklama: | Sunucunun kendi adını ve portunu nasıl belirleyeceğini ayarlar
Sözdizimi: | `UseCanonicalPhysicalPort On|Off`
Öntanımlı: | `UseCanonicalPhysicalPort Off`
Bağlam: | sunucu geneli, sanal konak, dizin
Durum: | Çekirdek
Modül: | core

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

### Ek Bilgi

Fiziksel port kullanımı etkin olduğunda işlemler şu sırayla yürütülür:
`UseCanonicalName On`

- `Servername` yönergesinde belirtilen port
- Fiziksel port
- Öntanımlı port

`UseCanonicalName Off | DNS`

- `Host:` başlığından çözümlenen port
- Fiziksel port
- `Servername` yönergesinde belirtilen port
- Öntanımlı port

`UseCanonicalPhysicalPort Off` olduğunda işlem sırasında fiziksel port adımları atlanır.

### Ayrıca bakınız:

- `UseCanonicalName`
- `ServerName`
- `Listen`

## <VirtualHost> Yönergesi

Açıklama: | Sadece belli bir konak ismine ve porta uygulanacak yönergeleri barındırır.
Sözdizimi: | `<VirtualHost adres[:port] [adres[:port]] ...> ... </VirtualHost>`
Bağlam: | sunucu geneli
Durum: | Çekirdek
Modül: | core

`<VirtualHost>` ve `</VirtualHost>` birlikte sadece belli bir sanal konağa uygulanacak yönergeleri sarmalamakta kullanılırlar. Bir sanal konak kapsamında belirtilebilecek her yönerge kullanılabilir. Sunucu belli bir sanal konak üzerindeki bir belge için bir istek aldığında `<VirtualHost>` bölümünde bulunan yapılandırma yönergelerini kullanır. adres şunlardan biri olabilir:

- Sanal konağın IP adresi.
- Sanal konağın IP adresi için tam nitelenmiş alan adı (önerilmez).
- `NameVirtualHost *` ile birlikte tüm IP adresleri ile eşleşmek üzere `*` karakteri.
- Sadece IP sanal konaklarında kullanmak için eşleşmeyen IP adreslerini yakalamak amacıyla `_default_` dizgesi.

### Örnek

`<VirtualHost 10.1.2.3:80>
ServerAdmin webmaster@konak.mesela.dom
DocumentRoot /www/docs/konak.mesela.dom
ServerName konak.mesela.dom
ErrorLog logs/konak.mesela.dom-error_log
TransferLog logs/konak.mesela.dom-access_log
</VirtualHost>`

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

`<VirtualHost [2001:db8::a00:20ff:fea7:ccea]:80>
ServerAdmin webmaster@konak.mesela.dom
DocumentRoot /www/docs/konak.mesela.dom
ServerName konak.mesela.dom
ErrorLog logs/konak.mesela.dom-error_log
TransferLog logs/konak.mesela.dom-access_log
</VirtualHost>`

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

### Ek Bilgi

`<VirtualHost>` kullanımı Apache’nin dinleyeceği adresler üzerinde belirleyici değildir. Apache’nin doğru adresi dinlediğinden emin olmak için `Listen` kullanmanız gerekebilir.

IP’ye dayalı sanal konakları kullanıyorsanız, diğer sanal konaklarda açıkça belirtilmemiş IP adresleriyle eşleşecek sanal konağı `_default_` özel ismiyle belirtebilirsiniz. "Ana" sunucu yapılandırmasında `_default_` diye bir sanal konağın bulunmaması halinde, hiçbir IP adresi eşleşmesi bulunamadığı takdirde `<VirtualHost>` bölümleri dışında kalan tüm yapılandırmalar bu amaca yönelik olarak kullanılır. (Yalnız dikkat edin, bir `NameVirtualHost` yönergesi ile eşleşen bir IP adresi için ne "ana" sunucu yapılandırması ne de `_default_` sanal konak yapılandırması kullanılır. Bu konuda daha ayrıntılı bilgi için isme dayalı sanal konaklar belgesine bakınız.)

Eşleşilecek portu değiştirmek için bir `:port` belirtebilirsiniz. Port bu şekilde değiştirilmediği takdirde ana sunucunun son `Listen` yönergesinde belirtilen port kullanılır. Bir adresteki tüm portlarla eşleşileceğini belirtmek için `:*` kullanabilirsiniz. (Bu, `_default_` kullanıldığı takdirde önerilir.)

Her `<VirtualHost>` bloku içinde bir `ServerName` yönergesi mutlaka olmalıdır. Yokluğu halinde "ana" sunucu yapılandırmasındaki `ServerName` miras alınacaktır (yani, sanal konak belirtmek için boşuna uğraşmış olursunuz).

### Güvenlik

Günlük dosyalarının sunucuyu çalıştıran kullanıcıdan başka herkes tarafından yazılabilen bir yerde saklanmasından dolayı ortaya çıkabilecek güvenlik sorunları hakkında daha ayrıntılı bilgi için güvenlik ipuçları belgesine bakınız.

### Ayrıca bakınız:

- Apache Sanal Konak Belgeleri
- DNS ile İlgili Konular ve Apache
- Apache’nin belli adresleri ve portları dinlemek üzere yapılandırılması
- 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 <Directory>, <Location> ve <Files> bölümleri nasıl çalışır? belgesine bakınız.

Mevcut Diller: de | en | fr | ja | tr